08. 경계간 매핑하기
- 매핑하지 않기 전략
- 서로 다른 레이어에서 같은 모델을 사용하여 개발
- 공통 모델에서 각 레이어별 다른 요구사항을 개발해야됨
- 모든 계층의 구조가 같을 경우 해당 전략을 추천
- 양방향 매핑하기 전략
- 계층 별로 다른 모델을 사용하여 개발
- 다른 계층의 요구사항을 개발하지 않아도 됨
- 너무 많은 보일러플레이트 코드가 생김
- 도메인 모델이 통신하는데 사용됨 (다른 레이어의 요구에 따른 변경에 취약해짐)
- 완전 매핑 전략
- 각 연산마다 별도의 모델을 사용
- 더 많은 코드가 필요함
- 구현하고 유지보수하기 쉬움
- 단방향 매핑하기 전략
- 공통 인터페이스를 개발한 후, 각 레이어에서 구현체를 구현
- 계층간의 모델이 비슷할 때 유용
- 언제 어떤 매핑 전략을 사용할 것인가?
- 그때그때 다르다.
- 한 전략을 전체 코드에 적용할 필요는 없음
- 팀내에서 가이드라인을 정해서 맞춰서 개발하는게 좋음
- 유지보수 가능한 소프트웨어를 만드는데 어떻게 도움이 될까?
- 정확한 가이드라인을 통해, 상황별로 맞는 전략을 가져가는게 좋음
09. 애플리케이션 조립하기
- 왜 조립까지 신경 써야 할까?
- 코드의 의존성을 관리하기 위해
- 안쪽에서 바깥쪽으로 의존성이 향해야함
- 이를 위해서는 설정 컴포넌트가 있어야함
- 설정 컴포넌트는 육각형 아키텍처의 가장 바깥쪽에 위치
- 커맨드라인 파라미터, 설정 파라미터 소스에 접근 가능해야함
- 평범한 코드로 조립하기
- 스프링을 사용안하는 경우로, 메인문에서 직접 각 클래스들을 정의하고 생성자를 통해 조립하는 방법
- 코드가 늘어날 수록, 관리하기가 어려움
- 클래스 접근제어자를 관리할 수 없어짐
- 스프링을 통해 해결 제안
- 스프링의 클래스패스 스캐닝으로 조립하기
- 스프링의 클래스패스 스캐닝으로 조립
- 클래스에 스프링 프레임워크 어노테이션이 붙어야하는 단점
- 라이브러리 사용자에게는 해당 방식으로 하면 안됨
- 유지보수 간, 프레임워크를 모르면 유지보수 힘듬
- 스프링의 자바 컨피그로 조립하기
- @Configuration을 이용해서 빈등록 후, 의존성을 관리
- 어노테이션을 강제하지는 않기 때문에 의존성이 적어짐
- 설정 클래스의 위치에 따라, 접근제어자 적용이 어려움
10. 아키텍처 경계 강제하기
- 경계와 의존성
- 의존성은 항상 안쪽으로 향해야한다.
- 접근 제한자
- 접근 제한자를 통해 각 경계를 분리하는 방법
- 컴파일 후 체크
- Archunit을 이용해서 각 경계를 테스트하는 코드를 작성하여 경계가 분리되었는지 확인
- 빌드 아티팩트
- 아티팩트 단위로 레이어를 분리해서 경계를 분리하는 방법
11. 의식적으로 지름길 사용하기
지름길 방지를 위해서는 지름길을 파악해야됨
- 왜 지름길은 깨진 창문 같을까?
- 품질이 떨어진 코드에서 작업할 때, 더 낮은 품질의 코드를 추가하기 쉽다.
- 코드 규칙을 많이 어긴 코드에서 작업할 때, 또 다른 규칙을 어기기도 쉽다.
- 지름길을 많이 사용한 코드에서 작업할 때 또 다른 지름길을 추가하기 쉽다.
- 깨끗한 상태로 시작할 책임
- 깨진 창문 방지를위해, 프로젝트를 깨끗이 시작하는게 좋음
- 의도적인 지름길은 세심하게 기록해야됨
- 유스케이스 간 모델 공유하기
- 유스케이스 간 입출력 모델을 공유하는것은 기능들이 묶여 있을 때 유효함
- 특정 세부사항을 변경할 경우, 둘다 영향을 주고 싶을 때는 사용 가능
- 도메인 엔티티를 입출력 모델로 사용하기
- 유스케이스가 복잡한 도메인 로직을 구현해야한다면, 유스케이스 인터페이스 별로 입출력 모델을 만들어야한다.
- 많은 유스케이스가 시작은 간단하지만, 시간이 흐르면서 복잡해지기 때문에, 해당 지름길은 잘 생각해봐야됨
- 인커밍 포트 건너뛰기
- 인커밍 포트는 의존성 역전에 필수적인 요소는 아님
- 전용 인커밍 포트를 유지하면, 한눈에 진입점을 식별 가능함
- 애플리케이션 서비스 건너뛰기
- 인커밍과 아웃고잉에서 모델을 공유해야한다.
- 시간이 흘러 도메인 로직이 복잡해지면, 아웃고잉 레이어에서 직접 구현하고 싶어진다.
- 코드 작성 효율을 위해 줄일수는 있지만, 복잡해지면 쓰는것을 추천
12. 아키텍처 스타일 결정하기
- 도메인이 왕이다.
- 외부의 영향을 받지 않고 도메인 코드를 자유롭게 발전시킬 수 있다는 것
- DDD와 매우 궁합이 좋음
- 경험이 여왕이다.
- 좋은 아키텍처 결정을 위해서는 다양한 아키텍처를 경험해보는 것이 좋음
- 작은 모듈에 클린 아키텍처를 적용해보고, 경험해보기
- 그때그때 다르다.
- 어떤 스타일의 아키텍처를 골라야하는것은 그때 그때 다르다.
반응형