[도메인 주도 설계] 05. 소프트웨어에서 표현되는 모델 (2)

SERVICE (서비스)

• 사물이 아닌 활동, 행동을 표현
• 다른 객체와의 관계를 강조하며, 클라이언트에 무엇을 제공할 수 있느냐에 따라 정의
• 서비스의 특징
  1. 연산이 ENTITY나 VALUE OBJECT의 일부를 구성하는 것이 아니라 도메인 개념과 관련돼 있다.
  2. 인터페이스가 도메인 모델의 외적 요소의 측면에서 정의된다.
  3. 연산이 상태를 갖지 않는다.

SERVICE와 격리된 도메인 계층

• SERVICE는 도메인 계층에서만 이용되는 것이 아니다.
• 각 계층의 SERVICE들을 구분하고 책임을 나누는데 주의를 기울여야 한다.
• 예제 - 자금이체서비스
  

구성 단위

• ENTITY와 VALUE OBJECT로부터 클라이언트를 분리하고, 도메인 계층의 인터페이스 구성 단위를 제어하는 수단
• 클라이언트 제어와 융통성보다는 인터페이스의 단순함이 더 중요
• 대형 시스템에서 분산 시스템에서 컴포넌트를 패키지화는데 유용한 중간 구성 단위의 기능을 제공

---

MODULE (모듈, 또는 패키지)

• 모듈로 쪼개지는 것은 코드가 아닌 개념이다.
• 사람이 한 번에 생각해 낼 수 있는 양에는 한계가 있으며(따라서 결합도는 낮춰야 한다),
  일관성 없는 단편적인 생각은 이해하기 어렵다(따라서 응집도는 높혀야 한다)
• 분할되는 객체의 의미에 따라 모듈을 선택해야 하며, 한 모듈 안에 든 개념은 한 번에 모아서 생각해야 하는 단위와 같다.

---

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

• 프레임워크의 분할 관례 탓에 도메인 객체 본연의 응집도가 불분명해진다.
• 프레임워크 분할에 매몰되어 모델을 도메인 요구에 맞게 조정하기 어려워진다.

모델링 패러다임

• 객체 패러다임이 지배적인 이유
  • 개념은 단순하지만, 도메인 지식을 포착할 만큼 풍부하다.
  • 모델을 소프트웨어에서 표현하게 해주는 도구가 지원된다.
  • 개발자 커뮤니티와 설계 문화가 성숙되어있다.
• 객체 세계에서 객체가 아닌 것들
  • 도메인 모델이 반드시 객체 모델이어야하는 것은 아니다.
  • 패러다임을 혼합해서 각 개념들이 가장 잘 어울리는 형식으로 모델링해야 한다.
• 패러다임이 혼재할 때 MODEL-DRIVEN DESIGN 고수하기
  • 룰 엔진같은 로직 패러다임은 객체의 약점을 보충해준다.
  • 하지만 데이터와 규칙 간의 연관관계가 단절되기 쉽다.
  • 두 가지 구현 패러다임에서 모두 작용할 수 있는 하나의 모델을 찾는 것이 중요하다.
  • 객체가 아닌 요소를 객체지향 시스템에 혼합하는 방법
    • 구현 패러다임을 도메인에 억지로 맞추지 않는다.
      - 도메인에 관한 사고방식은 반드시 하나만 있는 것이 아니다.
    • 유비쿼터스 언어에 의지한다.
      - 일관된 언어를 사용하면 설계의 각 부분이 분화되는 것을 방지할 수 있다.
    • UML에 심취하지 않는다.
      - 그리기 쉬운 방향으로 모델이 왜곡되지 않도록 해야한다.
    • 회의적이어야 한다.
      - 도구가 실제로 제 몫을 하고 있는가? 규칙이 있다고 반드시 룰 엔진이 필요한 것은 아니다.