계층형 아키텍쳐

• 기본적으로 아는 ‘web-domain-persistence’다.
• 보통 3계층 아키텍쳐라고 한다.
• 웹 -> 도메인 -> 영속성으로 호출 순서가 잡힌다.
• 꽤나 견고한 패턴이다. 이해만 잘하고 쓴다면 나쁠 것이 없다.
• 기존 기능에 영향을 주지 않고 새로운 기능을 추가할 수도 있다.
• DB 베이스 아키텍쳐다. DB에 특히 의존한다. 모든 것이 영속성을 토대로 시작된다.
• DB 구조에 맞춰서 도메인 로직을 구현하게 되고 이는 자연스럽다. 의존 방향에 맞춰서 개발하는 것이기 때문이다.
• 그러나 비즈니스 관점, 도메인 중심 개발에서는 다소 벗어난 방법이다.
• 시간이 지나면서 비즈니스 규칙을 영속성과 섞고 싶어지기 시작한다. 결과적으로 영속성과 도메인 간 강결합이 생긴다.
• 영속성 계층이 다른 계층을 쥐고 흔든다.
• 또는 계층을 건너뛰는 상상도 하게 된다. 당장은 shortcut으로 보이지만 결국에 발목을 잡는 길이 될 수도 있다.
• 애플리케이션 전반에 걸쳐 책임이 섞이고 핵심 도메인 로직들이 흩뿌려지게 된다.
• 테스트를 하기 위한 모킹 지점도 급격하게 증가한다. 이는 테스트 복잡도를 상승시킨다.
• 이런 상태는 추가 기능을 붙이기 위해서 손을 대기에 두려운 상태로 만들어 버린다.
• 추가적으로 크기에 대한 제한도 없기에 뚱뚱한 클래스가 도처에 널린다.
• 뒤섞인 의존성, 고구마처럼 딸려나오는 변경점. 높아진 복잡도에 따른 여러 merge conflict.

SRP, DIP

SRP

• 단일 책임 원칙, ‘컴포넌트를 변경하는 이유는 오로지 하나여야만 한다.’ 반대로 생각하면 변경할 때 손대야 할 곳이 한정되어야만 한다는 의미가 된다.
• 이는 ‘하나의 컴포넌트는 한 가지 일만 하고, 올바르게 수행해야 한다’고도 해석된다.
• 변경할 부분을 분리하고 캡슐화해서 파급도를 낮추는 식으로 진행하면 된다.
• 이는 하나의 변경점으로 딸려나오는 고구마 같이 여러 파생되는 변경점을 최소화 할 수 있게 해준다.

DIP

• 의존성이 생기면 변경이 전파되기 쉽다.
• ‘코드 상의 어떤 의존성이든 그 방향을 바꿀 수 있다’는 의미로 의존을 역전시켜서 이 전파를 억제하는 방향으로 이끈다.

그래서?

• 위와 같은 점들을 취합하면 모든 의존성을 안쪽으로 밀어 넣는, 책임을 세분화하는 방식으로 진행하면 된다.