[만들면서 배우는 클린 아키텍처] 03. 코드 구성하기

03. 코드 구성하기

코드 구성 전에 패키지 구조를 제대로 정의해야 추후 잘못된 방향으로 코드가 수정되거나 추가되지 않음

계층으로 구성

• 각 계층별 package를 구성
• 애플리케이션의 기능이나 특성을 구분 짓는 패키지 경계가 없음
  • 새로운 기능을 추가해야 하면 각 domain, persistence, web 패키지에 기능들을 추가
  • 기능이 점점 많아지면 서로 연관되지 않은 기능들끼리 연관될 수 있음
• 애플리케이션이 어떤 유스케이스를 제공하는지 파악하기 어려움
• 아키텍처를 파악하기 어려움

→ 각 내부 계층별로 애플리케이션마다 패키지 분리는 어떨까?

• domain/account/UsecaseService1
• domain/account/UsecaseService2
• ..

→ 더 세세하게는 애플리케이션마다 별도의 usecase를 패키지를 둔다면?

• domain/account/usecase1/service
• domain/account/usecase1/repository
• domain/account/usecase2/service
• domain/account/usecase2/repository
• …

기능으로 구성

• 어댑터를 나타내는 패키지나 인커밍 아웃고잉 포트를 확인할 수 없음
• 도메인 코드와 영속성 코드 간의 의존성을 역전했지만 도메인 코드가 실수로 영속성 코드에 의존하는 것을 막을 수 없음

아키텍처적으로 표현력 있는 패키지 구조

• 특정 상황에서 어느 부분에 작업을 해야할지 패키지 구조만 보고 찾을 수 있음
  • 서드파티 API 연동과 관련된 작업이 필요하다면 adapter/out/<어댑터 이름>으로 찾을 수 있다.
• 어댑터 패키지의 경우 외부 패키지에서 접근할 일이 없기 때문에 package-priavte으로 설정이 가능
• application 패키지와 domain 패키지 내의 일부 클래스는 public으로 둬야 함

의존성 주입 역할

• port 인터페이스를 구현한 adapter를 application(Service)에서 사용해야 하는데, 이때 구체적인 구현체를 누군가 제공해줘야 함
• 해당 부분에서 의존성 주입을 하는 컴포넌트를 이용해 넣어줄 수 있다.