소프트웨어 설계에 도메인 모델링이 중심이 되고 있습니다. 비즈니스 도메인을 중심으로 소프트웨어 개발자는 사용자의 요구를 충족시키는 풍부한 기능성을 표현하고 구현할 수 있어야 합니다. 도메인 전문가(a.k.a 현업)과 긴밀한 커뮤니케이션과 협력으로 효과적인 어플리케이션을 구축해야 합니다.
Manufacturing은 소프트웨어 개발에 널리 사용되는 메타포입니다. 이 메타포에 한 가지 추론할 수 있는 것은 고도로 숙련된 엔지니어는 제품을 설계하고, 덜 숙련된 노동자는 설계된 제품을 조립합니다. 많은 프로젝트는 메타포로 인해 실패하게 되었습니다. 소프트웨어 개발은 모두 디자인입니다. 모든 팀은 전문적인 역할을 가지고 있지만, 분석, 모델링, 설계 및 프로그래밍에 대한 과도한 책임 분리는 모델 주도 설계를 방해합니다.
Eric Evans, Domain-Driven Design
소프트웨어 코드의 구조와 언어(클래스명, 메소드, 변수)가 비즈니스 도메인과 일치해야 한다는 컨셉입니다. 예를 들어, 대출 신청 처리 소프트웨어를 개발한다고 할 때, 클래스에는 'LoanApplication', 'Customer'로 구성 할 수 있고, 메소드에는 'AcceptOffer'와 'Withdraw'로 작성 할 수 있습니다.
도메인 주도 설계의 핵심은 다음과 같습니다.
기술적으로 구현하기 위해서는 느슨한 결합(Loosly Coupling), High Cohesion
대부분의 사람들은 '설계를 고민한다는 것'이 '어떻게 생긴 것인지 고민하는 것'으로 착각한다. 설계자에게 어떤 박스를 주며 "좋아 보이게 만들어봐!" 수준으로 생각한다. 이건 우리가 생각하는 설계가 아니다. 설계는 단지 어떻게 생겼는지, 어떤 느낌인지가 아니다. 그게 어떻게 동작하는지에 대한 것이다.
Steve Jobs, Co-founder of Apple
참고) 카카오헤어샵의 도메인 모델 Entity 사용 예시
@Entity
class Reservation {
@Id
long id;
@ManyToOne
ServiceUser serviceUser;
@ManyToOne
Shop shop;
@ManyToOne
Product product;
}
다른 예시)
프로그램 대상 영역을 덩어리로 나누는 것을 말한다. 관련한 쉬운 비유가 있다.
주택을 짓는 경우에 빗대어 생각해 볼 때, Bounded Context는 주택 전체를 구성하는 헛간, 농장, 수영장, 메인 주택 등의 큰 요소들 각각을 둘러싼 상황을 의미합니다.
특정 모델은 어떤 bounded context에 놓이는가에 따라 다르게 이해될 수 있습니다.
실제 소프트웨어를 구축함에서의 예를 들면 가령 sales를 담당하는 subdomain이 있을 수 있고, 이를 지원하는 support와 accounting 라는 subdomain 이 존재할 수 있습니다. 이러한 각각의 subdomain이 놓인 환경인 bounded context 내에서 특정 모델 customer 가 보여지는 시각은 매우 상이할 수 있습니다. sales 팀에서 고객을 보는 시각은 주로 사회적 관심사, 좋아하는 것, 욕구 등의 것일 겁니다. 하지만 accounting의 측면에서는 사용자는 그저 하나의 계정으로써 그 사람의 결제정보 만이 중요한 정보일 수 있습니다. 즉 각기 다른 bounded context에서 ubiquitous language는 비록 표현은 같지만 다른 의미를 가지게 됩니다.
도메인을 정의하고 구성한다는 것은 사용자가 사용하는 영역을 정의하고 설계하는 것을 의미한다. 언뜻 DDD가 개발자에게 제약을 주는 것처럼 인식될 수 있으나, 그렇지만은 않다.
의존성이 높은 프로그램은 하나가 변경됐을 때 수정해야할 게 줄줄이 생기기 때문에 유지보수가 어렵다. 하지만 DDD에서는 도메인으로 개발 영역을 한정하고, 연결 관계(의존성)를 제어한다는 장점이 있다. UX/UI 설계를 통해 사용자가 사용할 수 있는 영역을 제한하고 제한된 영역 안에서 최적화한 경험을 설계할 수 있는 것과 마찬가지다. 사용자는 오히려 제한된 영역 안에서 더 나은 사용자 경혐을 할 수 있다.
또한 도메인(보편 언어)을 통해, 관계자 모두가 인지할 수 있는 범위 안에서 효율적으로 협업이 이루어질 수 있도록 한다. 사용자, 도메인 전문가(보통 PO, PM), 개발자가 명확하게 용어와 개발 범위를 인지함으로써 사용자를 위해 더 많은 것을 생각할 수 있는 길을 제공한다.