• 코드를 구성하는 몇 가지 방법을 소개한다.

• 소개할 예시들은 송금 서비스 BuckPal에 대한 것들이다.

• 특히 사용자가 본인의 계좌에서 다른 계좌로 돈을 송금할 수 있는 ‘송금하기’ 유스케이스에 대해 살펴본다.

계층으로 구성하기

buckpal
|
|--- domain
|     |--- Acount
|     |--- Activity
|     |--- AccountRepository
|     |--- AccountService
|
|--- persistence
|     |--- AccountRepositoryImpl
|
|--- web
      |--- AccountController

• 웹, 도메인, 영속성 계층 각각에 해당하는 전용 패키지인 web, domain, persistence를 둔다.

• DIP를 이용해 의존성이 domain 패키지에 있는 도메인 코드만을 향하도록 한다.

• 단 이 패키지는 최적의 구조가 아니다! → Why?

  1. 애플리케이션의 기능 조각이나 특성을 구분 짓는 패키지 경계가 없다.
     1. 즉, 서로 연관되지 않은 기능들끼리 예상하지 못한 부수효과를 일으킬 수 있는 클래스들의 엉망진창 묶음이 될 가능성이 높다!
  2. 애플리케이션의 어떤 유스케이스들을 제공하는지 파악할 수 없다.(개인적으로 이 부분은 패키지 구조 문제라기보다는 네이밍 문제라고 생각한다.)
     1. 특정 기능을 찾기 위해서는 어떤 서비스가 이를 구현했는지 추측해야 하고, 해당 서비스 내의 어떤 메서드가 그에 대한 책임을 수행하는지 찾아야 한다. (→ 2장에서 이야기했던 내가 □□□Service라는 네이밍을 싫어하는 이유 중 하나이기도 하다.)
  3. 패키지 구조를 통해서는 우리가 목표로 하는 아키택처를 파악할 수 없다. (목표로 하는 아키텍처가 헥사고날 아키텍처라고 가정)
     1. 어떤 기능이 웹 어댑터에서 호출되는지, 영속성 어댑터가 도메인 계층에 어떤 기능을 제공하는지 등을 한눈에 알아보기 힘들다.
     2. 인커밍 포트와 아웃고잉 포트가 코드 속에 숨게 된다.

기능으로 구성하기

buckpal
|
|--- account
      |--- Acount
      |--- AccountController
      |--- AccountRepositoryImpl
      |--- AccountRepository
      |--- SendMoneyService

• 계좌와 관련된 모든 코드를 최상위 account 패키지에 넣었다.