DDD 05장 - 소프트웨어에서 표현되는 모델 (2)

본 포스트는 도메인 주도 설계 라는 책을 참조하였습니다. 가능하면 본 책을 직접 보시고 DDD를 이해하는 것을 추천드립니다. http://www.aladin.co.kr/shop/wproduct.aspx?ItemId=12174216

Service

도메인의 개념 중 사물(도메인객체)이 아닌 활동이나 행동(연산)로 표현되는 모델링 대상

종종 이러한 연산은 여러 도메인 객체(Entity, Value Object)를 모아 그것들을 조율하는 행위

Service는 모델에서 독립적인 인터페이스로 제공되는 연산으로서 Entity나 Value Object와 달리 상태를 캡슐화 하지 않는다. Service는 흔히 사용되는 패턴이지만 Service는 도메인 계층에도 마찬가지로 적용될 수 있다.

• 모델에서 독립적인 인터페이스로 제공되는 연산
  • 클라이언트에 무엇을 제공할 수 있느냐?
• 상태를 캡슐화 하지 않음 : 연산 자체가 상태를 가질 필요가 없으므로 캡슐화 할 상태도 없는 것이다.

Service의 3가지 특징

• 연산이 원래부터 Entity나 Value Object의 일부를 구성하는 것이 아니라 도메인 개념과 관련돼 있다.
• 인터페이스가 도메인 모델의 외적 요소의 측면에서 정의된다. : Actor 즉, Use case diagram의 그것와 비슷??
• 연산이 상태를 갖지 않는다. : 연산에 영향을 주는 상태를 갖지 않는다 로 이해하면 편하다.
  • 하지만 특정 도메인의 경우 전역정보로 인한 사이드 이펙트는 있을 수 있다

요약

도메인의 중대한 프로세스나 변환 과정이 Entity나 Value Object의 고유한 책임이 아니라면 연산을 Service로 선언되는 독립적인 인터페이스로 모델에 추가하라. 모델의 언어라는 측면에서 인터페이스를 정의하고 연산의 이름을 Ubiquitous Language의 일부가 되게끔 구성하라. Service는 상태를 갖지 않게 만들어라.

Service와 격리된 도메인 계층

응용, 도메인, 인프라스트럭처 간 격리된 서비스

구성 단위

??

Service에 접근하기

??

Module

모듈, 패키지라고도 함

• 모듈화의 가장 큰 이유는 인지 과부하(cognitive overload) 방지
• 모듈도 낮은 결합도와 높은 응집도를 가져야한다.

모델 > 모듈 > 개념(도메인객체)

시스템의 내력을 말해주는 Module을 골라 일련의 응집력 있는 개념들을 해당 Module에 담아라. 이렇게 하면 종종 모듈 간의 결합도가 낮아지기도 하는데, 그렇게 되지 않는다면 모델을 변경해서 얽혀 있는 개념을 풀어낼 방법을 찾아보거나, 아니면 의미 있는 방식으로 모델의 각 요소를 맺어줄, Module의 기줄이 될 법한 것 중 미처 못보고 지나친 개념을 찾아보라. 서로 독립적으로 이해하고 논리적으로 추론할 수 있다는 의미에서 낮은 결합도가 달성되도록 노력하라. 높은 수준의 도메인 개념에 따라 모델이 분리되고 그것에 대응되는 코드도 분리될 때까지 모델을 정제하라.

Ubiquitous Language를 구성하는 것으로 Module의 이름을 부여하라. Module과 Module의 이름은 도메인에 통찰력을 줄 수 있어야 한다.

기민한 Module

Moduel를 리팩터링 하는 것은 부담이 큰 작업이므로 최소화해야하고 애초에 설계에서 부터 잘해야한다.

인프라스트럭처 주도 패키지화의 함정

패키지화는 모델에 따라야하지 기술이나 프레임워크에 따라가면 안된다. 즉 Layer(또는 Tier) 기준으로 패키징 하는 것은 피해야한다.

• 도메인모델의 응집력이 흩어진다. 즉 도메인 모델이 패키지별로 분리
• Layer와 패키지로 도메인모델 분리에 따른 복잡성이 증가

여러 서버에 코드를 분산 하는 것이 실제로 의도했던 바가 아니라면 동일한 객체는 아니더라도 하나의 개념적 객체를 구현하는 코드는 모두 같은 Module에 둬야한다.

패키지화를 바탕으로 다른 코드로부터 도메인 계층을 분리하라. 그렇게 할 수 없다면 가능한 도메인 개발자가 자신의 모델과 설계 의사 결정을 지원하는 형태로 도메인 객체를 자유로이 패키지화 할 수 있게 하라

모델링 패러다임

객체지향!!

객체지향 패러다임이 지배적인 이유

• 인간에게 직관적인 개념을 바탕으로 한 쉬운 접근
• 복잡함과 단순함의 조화
• 대중적인 개발자 커뮤니티와 높은 성숙도

지금은 객체지향 패러다임이 지배하지면, 영원하지는 않을 것이다.

객체 세계에서 객체가 아닌 것들

DDD에서는 도메인 모델을 바탕으로한 OOP 패러다임을 기반으로 하지만, 다른 요소들로 인해서 패러다임이 혼재할 수 있다.

ex 1) 인프라스트럭쳐 기술 중 관계형 패러다임을 가지는 RDB에 의존하는 경우 ex 2) 룰 패러다임

패러다임이 혼재할 때 Model-Driven Design 고수하기

확고한 Ubiquitous Languag를 바탕으로 패러다임 간 틈을 메꾼다

Model-Driven Design은 객체지향적일 필요는 없지만 모델의 구성물(객체, 규칙 ,워크플로우)은 OOP에 분명 의존한다.

객체가 아닌 요소를 객체지향 시스템에 혼합하는 4가지 법칙

• 구현 패러다임을 도메인에 억지로 맞추지 않는다.
• Ubiquitous Language에 의지한다.
• UML에 심취하지 않는다.
• 회의적이여야 한다.