의존성 역전
영속성 어댑터는 아웃고잉 어댑터이다. 어플리케이션에 의해 호출될 뿐, 어플리케이션을 호출하지는 않는다.
영속성 어댑터의 책임
1. 입력을 받는다.
2. 입력을 데이터베이스 포맷으로 매핑한다.
3. 입력을 데이터베이스로 보낸다.
4. 데이터베이스 출력을 어플리케이션 포맷으로 매핑한다.
5. 출력을 반환한다.
영속성 어댑터의 핵심은 영속성 어댑터 내부에 있는 것이 아니라 커플리케이션 코어에 있기 때문에 영속성 어댑터 내부를 변경하는 것이 코어에 영향을 미치지 않는다.
영속성 어댑터는 데이터베이스에 쿼리를 날리고 쿼리 결과를 받아온다. 데이터베이스 응답을 포트에 정의된 출력 모델로 매핑해서 반환한다.
포트 인터페이스 나누기
데이터베이스 연산에 의존하는 각 서비스는 단 하나의 메서드만 사용하는 것이 옳다. 이렇게 하더라도 단 하나의 '넓은' 포트 인터페이스를 사용하게 된다면 불필요한 의존성이 생긴다.
"필요없는 화물을 운반하는 무언가에 의존하고 있으면 예상하지 못했던 문제가 생길 수 있다."
인터페이스 분리 원칙를 적용해서 클라이언트가 오로지 필요로하는 메서드에만 특화되도록 인터페이스를 분리해야한다.
위와 같은 구조는 서비스코드를 짤 때 필요한 포트에 그저 꽂기만 하면 된다.
영속성 어댑터 나누기
포트를 나누었지만 하나의 영속성 어댑터는 모든 포트들에 의존하고 있다. 하지만 영속성 연산이 필요한 도메인 클래스 하나당 하나의 영속성 어댑터를 구현하는 방식을 선택할 수 있다.
이런 선택은 영속성 어댑터들이 영속성 기능을 이용하는 도메인 경계를 따라 자동으로 나뉘어 진다. 이것을 애거리거트당 하나의 영속성 어댑터 접근 방식과 바운디드 컨텍스트의 영속성 요구사항을 분리하기 위한 좋은 토대가 된다.
바운디드 컨텍스트란 서로 간의 어댑터를 접근하지 않는 것을 의미한다. 위의 그림에서 AccountPersistenceAdapter와 BillingPersistenceApdater 서로에게 접근하지 않는다. 만약 필요하다면 인커밍 포트를 통해 접근해야 한다.
데이터베이스 트랜잭션은 어떻게 해야 할까?
영속성 어댑터는 어떤 데이터베이스 연산이 같은 유스케이스에 포함되는지 알지 못하지 때문에 언제 트랙재션을 열고 닫을지 결정 할 수 없다. 영속성 어댑터를 호출을 관장하는 서비스에 위임해야 한다.
'Theory > Architecture' 카테고리의 다른 글
경계 간 매핑하기 (0) | 2022.07.09 |
---|---|
아키텍처 요소 테스트하기 (0) | 2022.07.05 |
웹 어댑터 구현하기 (0) | 2022.06.29 |
유스케이스 작성하기 (0) | 2022.06.21 |
코드 작성하기 (0) | 2022.06.20 |
댓글