도메인 주도 설계란?

• 말 그대로 도메인을 중심으로 설계해 나가는 방법

그럼 도메인이란 무엇일까?

• 소프트웨어로 해결해야할 문제의 영역

소프트웨어의 존재에 대한 가치

• 소프트웨어의 본질은 해당 소프트웨어의 사용자를 위해 도메인에 관련된 문제를 해결하는 능력에 있음
• 아무리 기술적으로 정교하고 뛰어난 성능을 갖추더라도 당면한 문제를 해결하지 못하는 소프트웨어는 실패한 소프트웨어라고 할 수 있음.
• 얼마나 빠른가, 얼마나 많이 처리할 수 있나, 얼마나 많은 사람이 붙어서 사용할 수 있나 등은 나중 이야기다.

기존 개발의 문제점(비즈니스 로직의 위치)

• 데이터베이스 위주의 개발 (데이터베이스 모델링을 중요시)
  • 서비스에는 흐름제어 로직밖에 없고 비즈니스 규칙과 개념들은 SQL에 존재함
  • 이렇게 비즈니스 로직과 저장 기술이 강하게 결합되어 있는 구조인 경우, 저장소를 변경하기 쉽지 않음
  • 또한 성능 측면에서 성능을 데이터베이스에 의존됨
  • 이러면 데이터가 많아졌을 때 데이터베이스의 성능은 지속적으로 떨어지고 이를 최적화 하기 위해 데이터베이스 서버의 사양과 용량을 계속 증가시키고 쿼리 튜닝에 몰두할 수 밖에 없음
  • 클라우드 인프라를 사용한 자동 스케일 아웃은 의미가 없어짐
  • 정작 바쁜 것은 데이터베이스이기 때문에 어플리케이션을 아무리 스케일 아웃해봐야 효과는 미미함
• 트랜잭션 스크립트 패턴

  • 서비스(Spring에서 사용되는 Service를 말함)에 모든 비즈니스 로직이 있고 비즈니스 절차에 따라 도메인 객체를 이용해 처리함

  • 도메인 객체는 단지 속성값만 이용되는 정보 묶음의 역할만 하게 됨

  • 서비스는 유스케이스 처리의 단위이고 대부분의 비즈니스 로직 처리가 서비스에서 이뤄지므로 비슷한 유스케이스의 경우 서비스에 중복되는 코드가 계속 생겨날 수 있고 이런한 점이 유지보수를 어렵게 함

  • 비즈니스 로직을 테스트하기 위해 Mocking을 해야하고 이는 테스트의 복잡성을 높이고 관리하기 어려운 테스트 코드를 발생시킴

    

    트랙잭션 스크립트 패턴

그럼 비즈니스 로직은 어디에 있는 것이 좋을까?

• 도메인 모델 패턴
  • 도메인 객체가 속성뿐만 아니라 비즈니스 행위를 가지고 있어 책임을 수행하게 됨
  • 서비스의 책임들이 도메인으로 분산되기 때문에 서비스의 메서드는 단순해짐
  • 거대한 서비스 클래스 대신 각기 적절한 책임을 가진 여러 클래스로 구성되므로 이해하기 쉽고 관리 및 테스트하기 쉬운구조를 가짐
• 잘 정의된 도메인 모델은 코드양을 줄이고 재사용성도 높음
• 도메인 모델 패턴은 도메인 주도 설계의 애그리거트 패턴을 적용할 수 있는 구조임

도메인 주도 설계

• 도메인 주도 설계는 크게 전략적 설계와 전술적 설계로 나눔
• 전략적 설계
  • 도메인 전문가 및 기술팀이 함께 모여 유비쿼터스 언어를 통해 도메인 지식을 공유 및 이해하고
  • 이를 기준으로 개념과 경계를 식별해 바운디드 컨텍스트(bounded context)로 정의하고
  • 경계의 관계를 컨텍스트 맵(context map)으로 정의하는 활동