https://refactoring.guru/ko/design-patterns/command

https://refactoring.guru/ko/replace-method-with-method-object

• Use case는 Stateless하게 관리되어야 한다.

  • Entities: Business Objects (DDD의 Strategy Pattern)

• 비지니스 → 도메인 로직 / 어플리케이션 로직

  • 도메인 로직은 어플리케이션과 독립적이다

• Boundary object로 Partitioning진행

• Use case는 Details 없이

  • 사용자가 뭐한다 → 시스템이 뭐한다 티키타카만 기록
  • Command Pattern (Transaction) ⇒ field variabels (not state. not params)
  • Interactor는 상태를 가질까??

• 좋은 아키텍처는 Details, Delivery에 의존하지 않고 최대한 결정을 미룬다. UI 가 아니라 시스템의 의도가 중요하다!

• 메소드의 이름과 PR은 모두 의도를 드러내기 위함이다! → 왜 했는지!!

! Boundaries가 많아지면 Mapping Hell !

! 구현없이 설계만 하는 사람은 결국 구현이 불가능한 설계를 하게 된다 !

Interactors is stateless beans