이 글에서는 거래 스크립트의 자산을 활용하면서 DDD+Clean Archeitecture 시스템을 새로 개발하려는 시도를 소개한다.
아직 개발 중이라 큰 성과는 못 봤지만 비슷한 상황에 있는 분들에게 참고가 됐으면 좋겠습니다.

데이터 객체 중심의 기존 시스템

대상은 어떤 업무 응용 프로그램의 백엔드로 관계 데이터베이스(RDB)를 중심으로 많은 구성 요소가 이동하고 있다.
구성 요소는 비동기식 메시지 수신, 일회용, UI용 WebAPI 등 수십 가지 이동된 이미지입니다.

각 구성 요소의 입력과 출력, 논리 부분은 분리되어 있지만 데이터 접근의 실현은 공통적이다.
기본적으로 RDB표의 한 줄을 Getter/setter만 있는 데이터 대상에 비추고 반복해서 비벼서 결과를 저장하고 반환합니다.이것이 바로 이른바 사무 스크립트 모델이다.
또한 각 구성 요소의 구조는 아래 그림과 같은 차원 구조이다.

기존 시스템의 어려움

이 시스템을 계속 수정하면 각양각색의 문제를 볼 수 있다.

서비스 계층에서 처리된 데이터는 RDB를 직접 체크 아웃한 데이터 객체입니다.데이터 대상은 관심사와 일치하지 않는 필드가 있어 한 번에 많은 데이터 대상을 수집해야 한다.

서비스 층의 클래스 디자인은 규칙이 없기 때문에 데이터 대상을 어디서 어떻게 변경하는지 파악하기 어렵다.결과가 어떻게 나올지는 처음부터 복잡하게 뒤엉킨 반에서 순서대로 추적 처리할 수밖에 없다.

코드와 관련이 없는 관리자(이른바 역전문가)와 요건을 압축할 때 현재 규격을 한 번 처리하지 않으면 대답할 수 없다.또한 수정을 진행할 때 시스템에 설치된 번역 작업은 두 번의 시간이 걸리고 필요한 조건과 오차가 발생할 수 있다.

에반스본이 접한 것은 이른바'역모델 빈혈증'에 빠진 상태였다.
이 문제들을 해결할 방법이 없습니까?해결책으로 주목되는 것은 DDD, Clean Architecture입니다.

DDD+Clean Archeitecture 적용

기존의 모든 팩스를 팩스로 보내기가 어려웠기 때문에 먼저 새로 개발된 구성 요소를 결정하는 데 대해 구조를 다시 고려하기로 했습니다.
새 어셈블리의 구속은 다음과 같습니다.

비동기 메시지 수발 처리를 진행한다.Message Queue에서 요청을 받고 처리한 후 Message Queue에서 다음 구성 요소에 다음 요청을 던집니다.

데이터 원본은 이전과 같다.액세스 테이블에서는 Data Access 레이어 설치를 사용할 수 있습니다.

미니 스타트 프로젝트 개발을 위해 잦은 수정을 계획하고 있다.

이러한 제한을 고려한 구조의 전체 상황은 다음과 같다.

Clean Archeitecture를 따라 기존 Data Access 레이어를 사용합니다.
내가 그 특징을 설명할게.

입력-처리-출력 단일행을 Clean으로

Controller를 통해 입력을 받아 Application에 적힌 순서대로 처리한 다음Presenter로 출력하면 Clean Archeitecture 모양이 됩니다.
여기서 중요한 것은 애플이 논리를 설정하지 않고 처리 순서만 기록하는 것이다.의식적으로 이걸 설계하면 복잡하게 얽힌 반을 쫓지 않고 어떤 처리를 하고 있는지 이해하기 쉽다.
실제 학급의 관계는 아래 그림과 같다.

인터페이스를 설정하면 입력과 출력의 실현에 의존하지 않을 수 있다.이렇게 하면 메시지 Quee의 방향 등을 변경할 때도 유연하게 대응할 수 있다.
이번에는 입력과 출력이 모두 메시지 Quee이기 때문에 출력 부분은 Presenter로 그렇게 채택되었다.
한편, 스프링 MVC 등의 웹API를 사용하는 경우 규격상 어렵다.(응답을 Controller의 반환값으로 되돌려야 하기 때문)
그런 경우에는 Presenter를 끄고 Controller로 반납하는 것이 좋습니다.1

도메인 모델을 만들고 객체를 Domain에 배치

애플은 처리 순서만 의식하고 Domain은 비즈니스 논리만 반영한다.
도메인 모델을 반영하는 클래스, 도메인 객체를 찾습니다.
도메인 이름 모델에 대해 역 전문가와 함께 고려한 후 조립합니다.
PlanetUML로 오브젝트 맵을 만들면서 진행하면 비교적 쉽다.다음 그림이 바로 예다.

(P.356, 그림10-7에 따라 제작되었다. 프로젝트 관리를 방해하는 도구에 필요한 후방 프로젝트의 역 모델을 고찰했다.)
역 모델과 그 실현된 역 대상은 기교가 필요하다.이 기사는 생략했지만 다른 DDD 관련 기사나 책을 읽으면 기억에 남을 것 같아요.

Gateway를 통해 도메인 객체와 데이터 객체의 차이점 흡수

역 대상은 상업 논리, 전문적으로'하고 싶은 일'의 대상이기 때문에 데이터베이스가 편리한 데이터 대상과 적응할 수 없다.
이러한 차이를 흡수하기 위해 Gateway는 데이터 대상과 영역 대상을 전환했다.
학급의 관계는 아래 그림과 같다.

Data Access 부분은 기존 시스템의 것을 사용해서 Gateway로 그것을 변환합니다.전환 처리가 전체적으로 Repository Impl에 놓여도 복잡해지기 때문에 비치는 반과Converter만 분리해서 정의합니다.
게이트웨이의 전환 덕분에 기존 데이터 접근 부분의 실현을 계승하고 역모델을 활용한 디자인도 구축했다.
또 향후 RDB 자체가 교체되더라도 게이트웨이 이하 내용을 수정하면 논리에 영향을 주지 않을 수 있다.

총결산

DDD+클린 어치텍처를 활용해 이전 자산을 활용하면서 보수성이 높은 디자인을 완성했다고 생각한다.
아직 노력 중이지만 소감은 이렇다.

기존 RDB 접속의 실현을 사용할 수 있고 작업 시간을 줄이는 동시에 클린을 실현할 수 있다.

학급 설계의 규칙이 결정되기 때문에 어디에 무엇을 쓸지 망설이지 않는다.

도메인 전문가와의 불일치를 줄이고 수정을 계속할 수 있다.

이어서 나는 실장에 초점을 맞춘 문장을 좀 더 쓰고 싶다.
nrs씨의 자바 구현 기사를 참고하십시오: https://nrslib.com/clean-architecture-with-java/↩