1. 단일 책임 원칙(Single Responsibility Principle,SRP)
- 일반적인 해석 하나의 컴포넌트는 오로지 한 가지 일만 해야하고, 그것을 올바르게 수행해야 한다
- 위의 일반적인 해석이 틀린말은 아니지만, 단일 책임 원칙의 실제 의도는 다음과 같다 "컴포넌트를 변경하는 이유는 오직 하나뿐이어야 한다."
- 단일책임 원칙이 지켜지고 있지 않는 예시
*실선 : 의존성
*점선 : 전이 의존성 (프로그램이 참조하는 컴포넌트로 부터 전이된 의존성)
- 그림에서 주목해야할 컴포넌트
- 의존하는 컴포넌트가 없는 E
- 모든 컴포넌트를 의존하고 있는 A
- 발생할 수 있는 문제
-
E의 기능을 바꿀 요구사항이 있을 때만 E를 변경하면 된다. 하지만, 컴포넌트 A의 경우에는 모든 컴포넌트에 의존하고 있기 때문에 다른 컴포넌트가 바뀌면 , 그에 맞춰서 같이 바뀌어야 한다.
-
ex)
B의 수정으로 인해 A에서 세운 로직에 문제가 생길 수 있다.
-
잘못 구조화된 소프트웨어의 경우, E와 같은 단일 책임원칙을 지키는 컴포넌트의 변경 또한 다른 부수효과를 발생 시킬수 있다.
시간이 갈수록 변경하기 어려워지고 이에 대한 비용이 증가한다. 한 컴포넌트의 수정이 다른 컴포넌트의 문제를 야기 할 수 있다.
-
-
1장의 그림1.2
- 도메인 계층이 영속성 계층에 의존하고 있다. 따라서 영속성 게층을 변경할 때마다 잠재적으로 도메인 계층도 변경해야 한다
- 이때 의존성을 역전 시킨다 (단, 서드파티 라이브러리에 대한 의존성은 해당 라이브러리를 제어할 수 없기 때문에 역전 불가)
-
도메인 계층에 영속성 엔티티를 표현하는 또 다른 엔티티를 만든다.
-
Repository Interface를 만들어 영속성 계층의 Repository 구현체가 해당 Interface를 의존하게 한다.
-
이때 Repository Interface 는 1번에서 만든 엔티티를 의존하게 한다
💡 결과 :도메인 계층의 영속성 계층에 대한 의존성이 사라지고
도메인 계층의 컴포넌트 간의 의존성 (domain entity <- repository interface)과
repository 구현체의 repository interface(in 도메인 계층)에 대한 의존성만 남게된다.
-
"클린 아키텍처에서는 설계가 비즈니스 규칙(도메인 코드가 구현)의 테스트를 용이하게 하고, 비즈니스 규칙은 프레임 워크, 데이터 베이스 , 그 밖의 외부 어플리케이션이나 인터페이스로 부터 독립적일 수 있다" — 이는 도메인 코드가 바깥으로 향하는 의존성이 없어야함을 의미한다
-
이 아키텍처의 계층들이 동심원으로 둘러싸여 있는 의미
의존성 규칙 : 계층 간의 모든 의존성이 안쪽으로 향해야 한다 (가장 중요한 규칙)
-
유스케이스는 단일 책임을 갖기 위해 좀더 세분화 돼있다.
-> 넓은서비스 문제 해결
-
도메인 계층과 영속성 계층간의 데이터를 주고받을 때 두 계층에서 사용하는 엔티티간의 변환이 이뤄저야 하는 번거로움이 있다.
~바람직한 일이고 8장에서 이에대한 매핑전략에 대해 다룬다.
-
클린 아키텍처의 원칙들을 조금 더 구체적으로 만들어준다.
-
어플리케이션 코어 육각형 내부에 있는 컴포넌트들을 의미한다
-
어댑터 왼쪽: 주도하는(driving) , 오른쪽: 주도되는(driven) 주도 여부는 코어와 어댑터 간의 호출 관계에 따라 달라진다
Driving adapter(주도하는) : 어댑터가 코어를 호출 ex)controller
Driven adapter(주도되는) : 코어가 어댑터를 호출 ex)repository
-
포트 input port(in port),output port(out port)
—포트는 육각형 내부의 어플리케이션 코어와 어플리케이션과 상호작용 하는 어댑터 들에게 인터페이스를 제공한다.
Input Port :
Driving adapter와 연결 ,육각형 내부에 있는 Use Case가 구현하고 , Driving Adapter가 호출한다.
Output Port :
Driven Adapter와 연결 ,Driven Adapter가 구현하고 , 어플리케이션 코어에서 호출한다.
-
마지막 계층에는 도메인 엔티티가 위치한다.
-
의존성 역전으로 도메인 코드가 다른 바깥족 코드에 의존하지 않게 함으로써 영속성을 비롯한 외부 기능에 특화된 문제로부터 도메인 로직의 결합을 제거 하고 코드변경의 이유의 수를 줄일 수 있다
--> 유지보수성은 더 좋아진다