<aside> 💡 이번 장에서는 코드를 구성하는 몇 가지 방법을 살펴보고, 육각형 아키텍처를 직접적으로 반영하는 표현력 있는 패키지 구조를 알아보자!

</aside>

새 프로젝트에서 가장 먼저 제대로 만들려고 하는 것은 패키지 구조다.

• 프로젝트에서 계속 사용할 괜찮아 보이는 구조를 잡는다.
  • 그러고 나서 프로젝트가 진행될수록 점점 바빠지고, 패키지 구조는 짜임새 없는 엉망진창 코드를 그럴싸하게 보이게 만드는 껍데기일뿐이라는 점을 깨닫게 된다.
  • 한 패키지에 있는 클래스들이 불러오지 말아야 할 다른 패키지에 있는 클래스들을 불러오게 된다.

→ 사용자가 본인의 계좌에서 다른 계좌로 돈을 송금할 수 있는 ‘송금하기’ 유스케이스를 살펴보자!

계층으로 구성하기

코드를 구조화하는 첫 번째 접근법은 계층을 이용하는 것으로, 다음과 같이 코드를 구성할 수 있다.

buckpal
		domain
				Account
				Activity
				AccountRepository
				AccountService
		persistence
				AccountRepositoryImpl
		web
				AccountController

• 여러 가지 이유로, 간단한 구조의 계층은 가장 적합한 구조가 아닐 수 있다.
  • 그래서 먼저 의존성 역전 원칙을 적용해서 의존성이 domain 패키지에 있는 도메인 코드만을 향하도록 해뒀다.
  • domain 패키지에 AccountRepository 인터페이스를 추가하고, persistence 패키지에 AccountRepositoryImpl 구현체를 둠으로써, 의존성을 역전시켰다.

그러나, 적어도 세 가지 이유로 이 패키지 구조는 최적의 구조가 아니다!

1. 애플리케이션의 기능 조각이나 특성을 구분 짓는 패키지 경계가 없다.

   • 이 구조에서 사용자를 관리하는 기능을 추가해야 한다면, web 패키지에 UserController 를 추가하고, domain 에 UserService , User 을 추가하고, persistence 에 UserRepositoryImpl 을 추가해야 한다.

2. 애플리케이션이 어떤 유스케이스들을 제공하는지 파악할 수 없다.

   • 특정 기능을 찾기 위해서는 어떤 서비스가 이를 구현했는지 추측해야 하고, 해당 서비스 내의 어떤 메서드가 그에 대한 책임을 수행하는지 찾아야 한다.