ch 10 아키텍처 경계 강제하기

각 계층은 언제나 안쪽 계층으로 의존성이 향하도록 강제하는 방법

접근 제한자
- public / protected / private / default 제한자
- 코틀린의 경우, public / protected / private / internal
- port / domain 의 경우는 public 으로 공개하며, 그 외의 구현체 등은 외부에서 접근하지 못하도록 한다.
ArchUnit 등을 이용하여 컴파일 후 체크
빌드 도구 를 이용하여 여러개의 빌드 아티펙트 (빌드 모듈) 로 나누기 https://www.youtube.com/watch?v=SrQeIz3gXZg

ch 11 의식적으로 지름길 사용하기

지름길은 깨진 창문과 같다.
깨끗한 상태로 시작하기
지름길이 실용적인 경우, 세심하게 기록하기

지름길의 종류

유스케이스 간 모델 공유하기

변경의 이유가 같은 경우는 공유해도 괜찮다.
반대로 생각하면, 특정 세부 사항을 변경할 경우에 두 유스케이스에 모두 영향을 주고 싶은 경우인 것이다.
두 유스케이스가 독립적으로 진화해야 한다면, 그때가 입출력 모델을 분리해야할 때이다.

도메인 엔티티를 입출력 모델로 사용하기

간단한 경우라면 사용할 수도 있음
하지만, MVP에서부터 시작하여 복잡도를 높여나가는 애자일 환경에서는 대부분 복잡한 도메인 로직 괴물로 변하기 때문에 해당 지름길은 위험하며, 도메인 모델과 입출력 모델을 분리해야할 시점을 잘 파악해야 한다.

인커밍 포트 건너뛰기

아웃고잉 포트는 의존성 역전을 위해 반드시 필요
인커밍 포트는 그렇지 않다.
하지만 인커밍 포트를 유지하는 이유는 애플리케이션 중심에 접근하는 진입점을 정의하며 / 아키텍철르 쉽게 강제할 수 있다.

애플리케이션 서비스 건너뛰기

단순 CRUD 라면 생략할 수 있다.
Spring data JPA + web support (https://docs.spring.io/spring-data/jpa/docs/current/reference/html/#core.web)
그렇지 않다면 서비스 계층을 추가하도록 한다.

결론

지름길을 실용적인 경우엔 좋다.
다만 지름길을 사용한 경우, 단순한 상태에서 언제 벗어날 지를 팀 내에서 합의한다.
또한 이를 왜 사용했는지에 대해 기록을 남긴다.

12. 아키텍처 스타일 정하기

도메인이 왕이다. / 경험이 여왕이다.
도메인 코드가 애플리케이션에서 가장 중요한 것이 아니라면, 육각형 아키텍처는 별로 필요하지 않을 것
습관이 나쁜 결정을 내릴 때 만큼, 좋은 결정을 내릴 때에도 도움이 된다.
그러므로, 좋은 결정을 내리려면 여러 아키텍처를 경험해봐야 한다.
육각형 아키텍처에 대한 확신이 없다면 지금 만들고 있는 애플리케이션의 작은 모듈에 먼저 시도해 본다.

아키텍처 경계 강제하기

일정 규모 이상의 프로젝트에서는 갈수록 아키텍처가 무너진다. 계층 간의 경계가 약화되고, 코드는 점점 더 테스트하기 어려워지고, 새로운 기능 구현에 많은 시간이 든다. 따라서 이를 막기 위한 방법이 몇 가지 제시된다.

경계와 의존성

아키텍처 경계를 강제한다는 의미는 경계가 명확한 헥사고날 아키텍처를 이용해서 의존성이 올바른 방향을 향하도록 하는 것이다. 즉, 잘못된 방향으로의 의존성을 없게 만드는 것이다.

언어의 문법을 통한 강제: 패키지

접근 제한자: '모듈'의 단위로 만들기 위해서 package-private 접근 제한자를 사용하고, 모듈의 진입점으로 활용될 클래스만 public으로 선언한다.
컴파일 후 체크: 의존성 규칙을 위반했는지 확인하기위해 ArchUnit같은 자동화 툴을 사용 가능

빌드 도구를 통한 강제: 빌드 아티팩트

빌드 아티팩트는 빌드 프로세스의 결과물이다. 메이블과 그레이들과 같은 빌드 도구가 있으며, 주요 기능 중 하나는 의존성 해결이다. 즉, 코드베이스가 의존하고 있는 모든 아티팩트가 사용 가능한지 확인하는 것이다.

이를 활용해서 모듈과 아키텍처의 계층 간의 의존성을 강제할 수 있다. 별도의 빌드 모듈인 JAR파일을 만들어서 컴파일 에러가 없을 때까지 의존성을 분리시킬 수 있다.

하지만 이 방법은 너무 극단적인 방법이 아닌가 하는 생각이 든다. 물론 잘 설계되어있고 이를 잘 지켜나간다면 훌륭한 방법임은 틀림없다.

의식적으로 지름길 사용하기

지름길을 방지하기 위해서는 먼저 지름길 자체를 파악해야 한다. 지름길은 깨진 창문과 같아서 클린 아키텍처의 반대 방향으로 가기 쉽다.

지름길 유형: 의식적으로 피해야 할 습관

유스케이스 간 모델 공유하는 경우: 유스케이스 간에 모델을 공유하게 되면 공유하는 유스케이스 간에 결합이 생긴다.
도메인 엔티티를 입출력 모델로 사용하는 경우: 엔티티를 공유하는 포트 간에 결합이 생긴다. 유스케이스의 변경이 도메인 엔티티까지 전파될 수 있다.
인커밍 포트 건너뛰기: 인커밍 어댑터가 인커밍 포트없이 애플리케이션 서비스에 직접 접근하게 되면, 내부 동작에 대해 잘 알아야 한다.
애플리케이션 서비스 건너뛰기: 애플리케이션 서비스를 건너뛰고 바로 영속성의 영역에 접근하고 싶을 수 있다. 하지만 이렇게 되면 나중에 CRUD 유스케이스가 복잡해지고, 도메인 로직을 그대로 아웃고잉 어댑터에 추가하게 되면 도메

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

복잡한 아키텍처에서 단순한 아키텍처로 바꾸는 것은 비교적 쉽다. 하지만 단순한 아키텍처에서 코드와 로직을 복잡해진 상태로 복잡한 아키텍처로 변환하기는 매우 어렵다. 그래서 초반에는 최대한 추상화 시켜서 작성하는게 좋겠다는 생각이 든다. 지름길은 최대한 피하도록 하자.

아키텍처 스타일 결정하기

외부의 영향을 받지 않고 도메인 코드를 자유롭게 발전시킬 수 있다는 것은 헥사고날 아키텍처 스타일이 내세우는 가장 중요한 가치다.

DDD에서 헥사고날 아키텍처는 매우 유용하다. 반대로 도메인이 애플리케이션에서 중요한 가치가 아니라면 헥사고날 아키텍처를 굳이 사용할 필요는 없다.

습관 = 편함 = 익숙함은 새로운 아키텍처 스타일을 적용하는 것을 거부하게 만든다. 최대한 객관적인 선택을 하려면 먼저 작은 프로젝트에 적용 및 활용해보는 것이 좋다.

BackendSquid / buckpal

chapter 10, 11, 12 #21