[클린 아키텍처] 아키텍처 요소 테스트 전략 & 경계 간 매핑하기

육각형 아키텍처에서 사용하는 전략

• 도메인 엔티티를 구현할 때는 단위 테스트로 커버하자
• 유스케이스를 구현할 때는 단위 테스트로 커버하자
• 어댑터를 구현할 때는 통합 테스트로 커버하자
• 사용자가 취할 수 있는 중요 애플리케이션 경로는 시스템 테스트로 커버하자

경계 간 매핑하기

각 계층의 모델을 매핑하는 것에 대해

• 매핑에 찬성하는 개발자
  • 두 계층 간에 매핑을 하지 않으면 양 계층에서 같은 모델을 사용해야 하는데 이렇게 하면 두 계층이 강하게 결합됩니다.
• 매핑에 반대하는 개발자
  • 하지만 두 계층 간에 매핑을 하게 되면 보일러플레이트 코드를 너무 많이 만들게 돼요. 유스케이스들이 오직 CRUD만 수행하고 계층에 걸쳐 같은 모델을 사용하게 되기 때문에 계층 사이의 매핑은 과합니다.

매핑하지 않기 전략

                                                |→                            Account                         ←|

                                               |                                        |                                    |

AccountController → SendMoneyUseCase ← SendMoneyService → UpdateAccountStatePort ← AccountPersistenceAdapter

웹 계층에서는 웹 컨트롤러가 SendMoneyUseCase 인터페이스를 호출해서 유스케이스를 실행한다.

이 인터페이스는 Account를 인자로 가진다.

즉, 웹 계층과 애플리케이션 계층 모두 Account 클래스에 접근해야 한다는 것을 의미한다.

반대쪽도 마찬가지다.

그런데 이 설계의 결과는 어떨까?

Account 클래스는 웹, 애플리케이션, 영속성 계층과 관련된 이유로 인해 변경되어야 하기 때문에 단일 책임 원칙을 위반한다.

모든 계층이 정확히 같은 구조의, 정확히 같은 정보를 필요로 한다면 ‘매핑하지 않기’ 전략은 완벽한 선택지다.

그러나, 애플리케이션 계층이나 도메인 계층에서 웹과 영속성 문제를 다루게되면 곧바로 다른 전략을 취해야 한다.

‘양방향’ 매핑 전략

각 계층이 전용 모델을 가진 매핑 전략을 ‘양방향’ 매핑 전략이라고 한다.

웹 계층에서는 웹 모델을 인커밍 포트에서 필요한 도메인 모델로 매핑하고, 인커밍 포트에 의해 반환된 도메인 객체를 다시 웹 모델로 매핑한다.

영속성 계층은 아웃고잉 포트가 사용하는 도메인 모델과 영속성 모델 간의 매핑과 유사한 매핑을 담당한다.

각 계층이 전용 모델을 가지고 있기 때문에 각 계층이 전용 모델을 변경하더라도 다른 계층에는 영향이 없다.

→ 단일 책임 원칙 만족

‘양방향’ 매핑 전략도 은총알이 아니다. 이는 개발을 불필요하게 더디게 만든다. 어떤 매핑 전략도 철칙처럼 여겨져서는 안된다. 그 대신 각 유스케이스마다 적절한 전략을 택할 수 있어야한다.

완전 매핑 전략

 

각 연산마다 별도의 입출력 모델 사용

전역적으로 쓰지말고 웹 계층과 애플리케이션 계층 사이에서 상태 변경 유스케이스의 경계를 명확하게 할 때 가장 빛을 발한다.

단방향 매핑 전략

 

 

모든 계층의 모델들이 같은 인터페이스를 구현

도메인 모델 자체는 풍부한 행동을 구현할 수 있고 애플리케이션 계층 내의 서비스에서 이러한 행동에 접근할 수 있다. → 도메인 객체를 바깥 계층으로 전달하고 싶으면 매핑 없이 할 수 있다.

팩터리라는 DDD 개념과 잘 어울린다.

층 간의 모델이 비슷할 때 효과적

언제 어떤 매핑을 사용할 것 인가?

매핑 전략은 개발 시간과 유지 보수성에 대한 트레이드오프

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

상황별로 매핑 전략을 선택하는 것은 모든 상황에 같은 매핑 전략을 사용하는 것보다 분명 더 어렵고 더 많은 커뮤니케이션을 필요로 하겠지만 매핑 가이드라인이 있는 한, 코드가 정확히 해야 하는 일만 수행하면서도 더 유지보수 하기 쉬운 코드로 팀에 보상이 되어 돌아올 것이다.