코드 구성하기

(해당 내용은 '만들면서 배우는 클린 아키덱처'의 책을 공부하여 정리한 내용입니다) 

계층으로 구성하기

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

웹, 도메인, 영속성을 계층별로 각각 계층별로 만들었다

의존선 역적 원칙을 적용해서 의존성이 domain 패키지에 있는 도메인 코드만 향하도록 했다

여기서는 domain 패키지에 AccountRepository 인터페이스를 추가하고, persistence 패키지에 AccountRepositoryImpl 구현체를 둠으로써 의존성을 역전시켰다

 

하지만 이 구조는 최적의 구조가 아니다

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

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

셋째, 우리가 목표로하는 아키텍쳐를 파악할 수 없다

 

기능으로 구성하기

계좌와 관련된 모든 코드를 최상위에 account 패키지에 넣었다는 점이 제일 변했고 계층 패키니들도 없앴다

이러한 패키징 방식은 아키텍처의 가시성을 훨씬 더 떨어뜨린다

 

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

육각형 아키텍처에서 구조적으로 핵심적인 요소로 표현한 패키지 구조

구조의 각 요소들은 패키지 하나씩에 직접 매핑된다

이런 패키지의 형태는 서로간의 이해를 돕고 한눈에 어느부분에서 어떤일이 일어날지 예상할 수있다

만약 패키지 구조가 아키텍처를 반영할 수 없다면 시간이 지남에 따라 코드는 점점 목표하던 아키텍처로부터 멀어지게 될 것이다

 

이 패키지 구조의 또 다른 매력적인 장점은 DDD 개념에 직접적으로 대응시킬 수 있다는 점이다

domain 패키지 내에서는 DDD가 제공하는 모든 도구를 이용해 우리가 원하는 어떤 도메인 모델이든 만들 수 있다

 

완벽한 방법은 없다 그러나 표현력 있는 패키지 구조는 적어도 코드와 아키텍처 간에 갭을 줄일 수 있게 해준다

 

의존성 주입의 역할

패키지의 구조가 클린 아키텍처에 도움이 되기는 하지만, 클린 아키텍처의 가장 본질적인 요건은 2장에서 배웠든이 애플리케이션 계층이 인커밍/아웃고잉 어댑터에 의존성을 갖지 않는 것이다

 

AccountController가  SendMoneyUseCase 인터페이스를 필요로 하기 때문에 의존성 주입을 통해 SendMoneyService 클레스의 인스턴스를 주입한다

 

SendMoneyService 인스턴스를 만들 때도 의존성 주입 메커니즘이 LoadAccountPort 인터페이스로 가장한 AccountPersistenceAdpter 클래스 인스턴스를 주입할 것이다

 

유지보수 가능한 소프트웨어를 만드는 데 어떻게 도움이 될까?

코드에서 아키텍처의 특정 요소를 찾으려먼 패키지 구조를 탐색하면 된다

이로써 의사소통, 개발, 유지보수 모두가 조금 더 수월해진다

 

---

생각 정리

패키지를 좀 더 세부화 하자

좀 더 정리된 패키지의 구조는 소스파악이 쉽고 개발 및 유지보수가 쉽다

 

인터페이스들이 꼭 필요할까?

1:1로 매칭되는 Service와 Interface는 큰 의미가 없을것 같은데.. 사용해야 하는 이유는 뭘까?

인터페이스를 꼭 사용해야 하는경우

- 동일한 기능을 다른 방식으로 동작시키기 위한 인터페이스

- 동일한 결과물을 서로 다른 환경에서 같이 작업할경우 정의

인터페이스를 잘 사용하지 않으면 불필요할것 같은 생각이 자꾸 든다

 

In, Out  포트가 꼭 필요할까?

데이터 매핑을 시켜 각 계층마다 다른 데이터를 사용한다면

그것을 in, out 포트라고 봐도 될것 같다