변종활동을 하기전에 아키텍처를 선택하고 활용해보자 최고 설계 다음으로 좋은 설계는 나쁜설계이다. 이말은 아무런 설계없이 구현부터 시작하는것에대한 문제를 이야기하는것이다 - ddd의 어느문구중 |
DDD에서는 아키텍처가 별도로 있는것이 아니며, 위 아키텍처를 준수한다고
DDD의 목표에 도달하는것도 아니다. DDD를 실현하기 위해서는 위 아키텍처를
잘 이해하고 활용해야 할 필요가 있다.
해당 아키텍처에대한 설명은 그림과 링크로 대체합니다.
참고링크 : https://wikibook.co.kr/article/layered-architecture/
특이사항 : 계층을 잘 나눠 도메인을 분리하자~
참고링크 : https://woowabros.github.io/tools/2019/10/02/clean-architecture-experience.html
특이사항 : 같은 이야기이지만, SOA에서 활용이 주로 된듯
특이사항 : 도메인 이벤트를 활용하는 CQRS 영역까지 포함한 아키텍처입니다. 위에서 설명한 아키텍처를 계승하고 양념이 뿌려진듯
결국 아키텍처에서 공통으로 이야기하는 것은 관심사의 분리이며 각 아키텍처마다
동일하지만 분리하는 방식에 사용되는 용어가 약간 다르거나, 의존성을 구성하는 방법 접근방향등에
약간식의 차이가 있는것으로 보입니다.
DDD에서는 아키텍처에서 표현된 도메인 모델과 코드의 일치성을 중요하게 생각하며 더나아가 코드로 도메인 모델이 설명이 되어야한다고 이야기 합니다. 이것은 도메인 코드를 작성하는 개발자가 곧 설계자여야하며 설계자와 코더로 이분화 되었을때, 코드는 결코 설계를 반영하지 않을것이다란 경고를 합니다. |
계층형 아키텍처를 선택하고 RestAPI에 DDD컨셉을 반영을 시도해보겠습니다.
왼쪽그림은 의존성이고 오른쪽은 의존에따른 호출방향입니다.
계층형 아키텍처를 이해했으면, 아키텍처와 구현부를 맵핑해보고 규칙을 만들어보자
구현해야할 도메인의 규모와 종류는 다를수 있으면 그에 따른, 적합한 아키텍처를 선택할수 있습니다.
여기서는 선택한 아키텍처와, 어플리케이션의 구현구조를 일치화하는것입니다.
이 아티컬에서 구현시도 예정인 Application Layout