만들면서 배우는 클린아키텍처를 읽고(1/4) (tistory.com)
2장. 의존성 역전하기
2.1. 단일책임원칙
- SRP(Single Responsibility Principle)
컴포넌트를 변경하는 이유는 오직 하나뿐이어야한다.
- 장점
- 응집력 향상 (Enhanced Cohesion)
- 결합도 감소 (Reduced Coupling)
- 유지보수성 향상
- 테스트 용이
- 하지만, 실세계의 소프트웨어에서 컴포넌트 의존성은 매우 복잡하기때문에, 변경하는 이유는 쉽게 전파됨
- 시간이 흐를수록 변경하는 이유들이 많아 지며, 많이 쌓인 후 컴포넌트를 변경하는건 다른 컴포넌트의 실패로 이루어짐
- 결론
- 복잡한 아키텍처에서는 컴포넌트 간 의존성 때문에 변경할 이유가 쉽게 전이되기때문에, 클린 아키텍처를 지향하는게 좋다(?)
2.2. 부수효과(Side Effects)에 관한 이야기
- 클라이언트가 사용자 입장에서 이상한 방식으로 동작하는 소프트웨어를 개발해달라고함
- 저자는 유지보수 개발자로써 소프트웨어의 코어 컴포넌트를 수정하여 사용자 친화적이며 저렴한 방법을 제안
- 클라이언트는 이전에 코어 컴포넌트를 수정하여 다른 기능들이 망가지는 부수효과(Side Effects)를 경험했었어서 코어를 바꾸자는 제안을 거절함
- 결론
- 좋은 소프트웨어를 만들도록 노력해보자 (클린아키텍처?)
2.3. 의존성역전원칙
- 계층형 아키텍처 특성에 따라 고수준 레이어에(ex. persistence layer) 변경이 발생할 경우, 저수준 레이어에서(ex. domain layer) 변경할 이유가 쌓이게된다. (저수준 레이어에서 고수준의 레이어들에 대한 의존성이 많음)
- 의존성 역전(Dependency Inversion Principle, DIP)를 적용하여 의존성을 제거하자
- 코드상의 어떤 의존헝이든 그 방향을 바꿀 수 있다.
- Repository의 인터페이스를 도메인 영역에 두고, 구현체를 영속성에 위치시키기
2.4. 클린아키텍처
- 클린아키텍처란?
- 설계가 비지니스 규칙의 테스트를 용이하게 하고
- 비즈니스 규칙은 프레임워크 데이터베이스, UI 기술 등의 인터페이스로부터 독립적일 수 있음 ⇒ 도메인코드가 바깥으로 향하는 어떤 의존성도 없어야함을 의미
- 계층간의 모든 의존성이 안쪽으로 향해야됨
- 계층별로 독립적이기 때문에 각 계층에서 엔티티를 관리해야된다.
2.5. 육각형 아키텍처(헥사고날 아키텍처)
- Application Core로 의존성이 향하며, 외부로부터 독립적임
- 포트와 어댑터 패턴으로 불리기도 함
- Application Core와 다른 계층이 상호작용을 하기위해 port를 통해 상호작용함
2.6.유지보수 가능한 소프트웨어를 만드는데 어떻게 도움이 될까?
- 각 계층을 독립적으로 구성하여 변경할 이유를 줄이는게 목적
- 특정 프레임워크나 라이브러리에 종속되지않고 순수한 도메인 계층을 작성할 수 있음
3장. 코드 구성하기
3.1. 계층으로 구성하기
buckpal
- domain
- persistence
- web
- 단점
- 애플리케이션을 기능단위로 구분할 수 없다.
- 어떤 유스케이스가 있는지 파악할 수 없다.
- 어떤 기능이 제공되는지 알 수 없다.
3.2. 기능으로 구성하기
buckpal
- acccount
장점
- 기능들의 패키지 간의 경계를 구분할 수 있음
단점
- 기능단위로 묶다보니 계층간의 의존성을 관리하기가 어려움
3.3. 아키텍처적으로 표현력 있는 패키지 구조
buckpal
- account
- adpater
- in
- out
- domain
- application
- port
- 아키텍처와 코드의 갭을 줄여줌
- 계층간 분리를 통해 변경하기 쉬움
- DDD를 적용하기 쉬움
3.4. 의존성 주입의 역할
- 아웃커밍 포트의 구현을 위해 중립컴포넌트를 도입한 후, 의존성 역전을 통해 의존성을 관리함
- 인커밍의 경우, 서비스가 웹 계층의 의존성을 갖지는 않지만, 분리해도 됨
3.5.유지보수 가능한 소프트웨어를 만드는데 어떻게 도움이 될까?
- 기능과 계층을 동시에 사용하여 표현력 있는 패키지 구조
반응형