Domain Driven Design – 2부 (Tactical Design)

by

2부. Tactical Design

Tactical Design Tool 들은 세부적인 사항을 구현하는 것을 위해 필요하며,

주로 Bounded Context 내의 구성 요소들을 관리합니다.

이것은 개발상의 실제적인 표준을 제공하는데 services, entities, repositories, factories 와 같은 소프트웨어 디렉토리 구조들에 익숙한 개발자들이 많을 것인데, 이 모든 것은 전부 DDD에서 나온 개념입니다.

이러한 Tactical Design은 Strategic Design과 달리 개발을 진행하는 과정에서 계속해서 바뀌고 개선됩니다.


Model Driven Design And Service

Tactical Design을 이해하기 위한 Model Driven Design은 위와 같습니다.

실제 구현은 모델 수준에서 이루어 지고 쉽게 비유하자면 당신의 소프트웨어 전체 즉,

domain을 하나의 세계로 표현한다면

각 나라는 subdomain에 해당되고 각 subdomain은 각 나라의 언어인 ubiquitous language를 사용하게 됩니다.

이렇게 각 subdomain은 하나의 Service로 구현되게 됩니다.


Layered Architecturelayered Architecture란 쉽게 말하면 모든 프로세스를 업무순서로 쪼게어 층을 나누어 수행하는 것입니다.가령 맥도날드의 예를 들어 맥도날드에서는 각 종업원들이 맡은 업무를 충실하게 수행하여 아주 효과적으로 업무를 처리합니다.만약 맥도날드의 종업원들이 요리, 계산, 서빙 등 많은 업무를 업무 분담 없이 하게 된다면 분명히 큰 혼란이 초래되고 손님들은 오랜시간 동안 기다려야 하고 형편없는 음식을 먹게 될 것입니다.하지만 맥도날드는 손님을 응대하는 계산원, 주문을 전달하고 컨트롤 하는 중간 매개인, 전체 프로세스에 필요한 인프라를 제공하는 요리사, 사장, 매니저, 필요한 재료들을 보관하는 창고 등으로 구성되어 빠르고 효과적으로 일을 처리합니다.소프트웨어에서도 마찬가지로 고객을 응대하는 request handler, 이를 중재하는 controller, 각종 중요한 비즈니스 로직을 처리하는 business, 다양한 자료구조 등으로 구성되어 클라이언트에 보다 빨리, 조직적으로, 잘 응대할수 있게 되었고, 이에 따라 보다 유연하고 지속가능한 소프트웨어를 구축할 수 있게 되었으며, 각 파트는 자신의 역할을 충실히 수행하고 필요한 경우 여러번 재사용 될 수 있게 됩니다.
계층구조(Layered Architecture)의 일반적인 모습
Value Object소프트웨어의 모델을 구성하는 수치에 대한 객체이며 훌륭한 디자인을위한 가장 중요한 요소 중의 하나입니다.가령 소프트웨어 내에 화폐를 취급하는 객체가 있다면,이는 화폐에 관한 모든 처리를 누군가의 도움 없이 스스로잘 처리할 수 있어야 합니다.단위 환산, 표현법 변경 등 다양한 도메인 로직을 가져야 하며,스스로 옳바른 값인지 validate 할 수 있어야 할 뿐 아니라 값이제 3자에 의해 변하지 않고 일관성을 유지해야 합니다.가령 string 객체=는 문자 어레이를 다루는 value object로써substring 등의 다양한 기능을 수행하기 때문에 이를 일일히정의할 필요가 없어져 ubiquitous language 로 소프트웨어의 표현을간단하게 하고 보강해 줍니다.
Entity기존의 attributes 를 기준으로 정의되었던 전통적인 객체와 달리,연속성의 일관된 스레드에 의해 식별되는 객체입니다.일반적인 개발자들이 이 개념에 대해 알고 있습니다.Entity는 Value Object로 구성되며 대표적인 예로 db에있는 row들의 예를 들 수 있습니다.Entity는 identified id 를 가지고 business logic을 구현합니다.
Aggregate 와 Domain Eventsaggregates는 entities의 집합입니다.가령 cutomer, customerInfo, address 라는 세가지 종류의 entities를 생각해 볼때,사실 이 모든 정보는 customer라는 주제로 뭉칠 수 있으며, 여기서 핵심이 되는entitiy인 customer는 이 세 entities가 이루는 aggregates의 root entity가 됩니다.이렇게 되면, 다른 외부 객체는 aggregate 내의 객체로 직접 접근할 수 없고,하나의 aggregate root item 즉 customer 에만 접근이 가능하며,이를 통해 해당 aggregate 내에 명령을 전달해야 합니다.이는 실제 프로그래밍에 자주 쓰이는 디자인 패턴 중의 하나입니다.더욱 간편한 예로는 포스트와 댓글의 관계, 질문과 답변의 관계 등이 있습니다.여기서 Domain Event 라는 개념에 대해 살표보면,domain event는 모델의 특정 행동과 관련된 이벤트인데,Aggregate 사이의 일관성을 유지하는데에 사용될 수 있습니다.가령 사용자의 주소가 바뀌면 주문 내용도 바뀌어야 하는데,순서를 살펴보면 사용자의 주소가 바뀌면 같은 aggregate내에 있는사용자 정보가 바뀌게 되고 이러한 aggregate의 변화는 주문과 관련된aggregate의 변화를 촉구하기 위해 domain event를 발생시켜상호간의 정보의 일치를 이룹니다.
FactoriesFactories는 복잡한 entity 혹은 aggregate를 생성하는 것을 담당합니다.가령 엔진과 부속품을 넣으면 자동차가 나오는 공장과 같이 특정 정보를factory에 보내면 결과로 aggregate 혹은 entity를 만들어주게 되고,그 안에서 벌어지는 일에 대해서는 개발자들이 더 이상 신경을 쓰지 않아도 되고,하나의 모듈로써 사용할 수 있습니다.
Repositories일반적인 저장소와 달리 특정 aggregate에 보다 신속하게 접근하고aggregate 단위로 데이터를 처리할 수 있게 해 줍니다.가령 위의 예처럼 customer 가 root entity로 있는 aggregate의 경우1개의 repo를 만들게 되고, 사용자는 더 이상 기존의 db에서 고객 이름,나이, 생년 등을 조합해서 사용하지 않고 repo에 aggregate를 통으로저장해서 보다 쉽게 정보에 접근하고 정보를 변경할 수 있습니다.
  • 업무를 가장 잘 이해하는 해당분야 전문가와 개발자 사이의 소통을 중심으로 특정 도메인을

개념적으로 표현한 모델을 통해, 여러 관계자들이 동일한 모습으로 도메인을 이해하고,

도메인 지식을 공유하는 것이 중요합니다.

고객의 요구사항이 모델로 유연하게 설계되고, 이 모델로부터 구현이 자연스럽게 연결되어야

한다는 사상이 Domain Driven Design 입니다.


참고사이트

Leave a Comment