도메인 중심 설계

Domain-driven design
시리즈의 일부
소프트웨어 개발
핵심 활동
패러다임 및 모델
방법론 및 프레임워크
지원 분야
프랙티스
도구들
지식의 표준과 본문
용어집
개요

도메인 기반 설계(DDD)는 해당 도메인 [2]전문가의 입력에 따라 도메인에 일치하도록 소프트웨어를 모델링하는 데 초점을 맞춘 소프트웨어 설계 방법입니다.

객체 지향 프로그래밍의 관점에서 이는 소프트웨어 코드(클래스 이름, 클래스 메서드, 클래스 변수)의 구조와 언어가 비즈니스 도메인과 일치해야 함을 의미합니다.예를 들어 소프트웨어가 대출 응용 프로그램을 처리하는 경우 Loan Application 및 Customer와 같은 클래스와 AcceptOffer 및 Draft와 같은 메서드가 있을 수 있습니다.

DDD는 구현을 진화하는 [3]모델에 연결합니다.

도메인 중심 설계는 다음과 같은 목표를 기반으로 합니다.

  • 프로젝트의 주요 초점은 핵심 도메인과 도메인 로직이다.
  • 도메인의 모델을 기반으로 한 복잡한 설계
  • 특정 도메인 문제에 대처하는 개념 모델을 반복적으로 개선하기 위해 기술 전문가와 도메인 전문가 간의 창의적인 협업을 시작합니다.

도메인 중심 설계에 대한 비판은 개발자가 모델을 순수하고 유용한 구성물로 유지하기 위해 일반적으로 상당한 분리 및 캡슐화를 구현해야 한다고 주장합니다.도메인 중심 설계는 유지관리성 등의 이점을 제공하지만 마이크로소프트는 이 모델이 [4]도메인에 대한 공통 이해를 형성할 때 명확한 이점을 제공하는 복잡한 도메인에만 권장하고 있습니다.

이 용어는 에릭 에반스가 2003년에 [5]출판한 동명의 책에서 만든 것이다.

개요

도메인 중심 설계는 많은 높은 수준의 개념과 [5]관행을 명확하게 나타냅니다.

가장 중요한 것은 도메인입니다.사용자가 프로그램을 적용하는 대상 영역은 소프트웨어의 도메인입니다.소프트웨어의 도메인은 의미를 결정하는 단어 또는 문장이 나타나는 설정인 컨텍스트를 제어합니다.이를 통해 개발자는 도메인의 선택된 측면을 기술하고 해당 도메인에 관련된 문제를 해결하는 데 사용할 수 있는 추상화 시스템인 도메인 모델을 구축합니다.

도메인 중심 설계의 이러한 측면은 유비쿼터스 언어를 육성하는 것을 목적으로 합니다.즉, 도메인 모델은 시스템 요건, 비즈니스 사용자, 스폰서 및 개발자에 의해 공유되는 공통 언어를 형성해야 합니다.

도메인 중심 설계에서 도메인 계층은 객체 지향 다층 아키텍처의 공통 계층 중 하나입니다.

모델의 종류

도메인 중심 설계는 여러 종류의 모델을 인식합니다.

예를 들어 엔티티는 속성이 아닌 ID에 의해 정의된 객체입니다.예를 들어, 대부분의 항공사는 모든 항공편의 좌석에 고유 번호를 부여합니다. 이것이 좌석의 식별 번호입니다.

반면 값 개체는 속성을 포함하지만 개념적 ID가 없는 불변의 개체입니다.예를 들어, 사람들이 명함을 교환할 때, 그들은 각각의 고유 카드를 구별하기 보다는 카드에 있는 정보(속성)에만 신경을 씁니다.

모델은 이벤트(과거에 발생한 일)를 정의할 수도 있습니다.도메인 이벤트는 도메인 전문가들이 관심을 갖는 이벤트입니다.

모델은 루트 엔티티에 의해 결합되어 집약이 될 수 있습니다.집약 외부에 있는 개체는 루트에 대한 참조를 유지할 수 있지만 집약의 다른 개체에 대한 참조는 유지할 수 없습니다.집약 루트는 집약 변경의 일관성을 확인합니다.예를 들어, 운전자는 자동차의 각 바퀴를 개별적으로 제어할 필요가 없다. 그들은 단지 차를 운전할 뿐이다.이 맥락에서 자동차는 여러 다른 물체(엔진, 브레이크, 전조등 등)의 집합체입니다.

모델 작업

도메인 중심 설계에서 객체의 생성은 객체 자체와 분리되는 경우가 많습니다.

예를 들어 저장소는 데이터스토어(예: 데이터베이스)에서 도메인 개체를 검색하는 방법을 가진 개체입니다.마찬가지로 팩토리는 도메인 개체를 직접 생성하는 방법을 가진 개체입니다.

프로그램 기능의 일부가 개념적으로 개체에 속하지 않는 경우 일반적으로 서비스로 표현됩니다.

다른 아이디어와의 관계

도메인 중심 설계는 본질적으로 객체 지향 접근법에 얽매이지 않지만, 실제로는 그러한 기술의 장점을 활용합니다.여기에는 명령어/메서드 호출의 리시버로서의 엔티티/집약 루트, 최상위 집약 루트 내의 상태 캡슐화 및 보다 높은 아키텍처 수준의 경계 컨텍스트가 포함됩니다.

그 결과 도메인 중심 설계는 보통 Plain Old Java Objects 및 Plain Old CLR Objects와 관련지어집니다.기술적인 실장의 상세(Java 및 에 고유)NET Framework라는 용어는 각각 도메인 객체를 보다 구체적인 기술 프레임워크가 아닌 단순히 도메인의 비즈니스 동작에 따라 정의해야 한다는 견해를 반영하고 있습니다.

마찬가지로, 나체 객체 패턴은 사용자 인터페이스가 충분히 좋은 도메인 모델을 반영하는 것일 수 있다고 생각합니다.사용자 인터페이스가 도메인 모델을 직접 반영하도록 요구하면 더 나은 도메인 [6]모델을 설계해야 합니다.

도메인 중심 설계는 소프트웨어 개발에 대한 다른 접근 방식에 영향을 미쳤습니다.

예를 들어 도메인 고유의 모델링은 도메인 고유의 언어를 적용한 도메인 중심 설계입니다.도메인 기반 설계에서는 도메인 고유의 언어를 사용할 필요가 없지만 도메인 고유의 언어를 정의하거나 도메인 고유의 멀티모델링을 지원하는 데 사용할 수 있습니다.

한편, 애스펙트 지향 프로그래밍을 사용하면 도메인 모델에서 기술적인 문제(보안, 트랜잭션 관리, 로깅 등)를 쉽게 배제할 수 있어 비즈니스 로직에만 집중할 수 있습니다.

모델 주도형 엔지니어링 및 아키텍처

도메인 중심 설계는 모델 중심 엔지니어링 및 [7]아키텍처와 호환되지만 두 가지 개념의 의도는 다릅니다.모델 중심 아키텍처는 보다 나은 도메인 모델을 정의하는 것보다 모델을 다른 기술 플랫폼용 코드로 변환하는 데 더 관심이 있습니다.

그러나 모델 중심 엔지니어링이 제공하는 기술(모델 도메인에 대한 기술, 도메인 전문가와 개발자 간의 커뮤니케이션을 촉진하기 위한 도메인별 언어 생성 등)은 실제로 도메인 중심 설계를 촉진하고 실무자들이 모델로부터 더 많은 것을 얻을 수 있도록 지원합니다.모델 구동 엔지니어링의 모델 변환 및 코드 생성 기술 덕분에 도메인 모델을 사용하여 [8]이를 관리하는 실제 소프트웨어 시스템을 생성할 수 있습니다.

명령어 쿼리 책임 분리

명령어 쿼리 책임 분리(CQRS)는 읽기 데이터('쿼리')를 쓰기에서 데이터('명령어')로 분리하기 위한 아키텍처 패턴입니다.CQRS는 Bertrand Meyer가 작성한 Command and Query Separation(CQS; 명령어 및 쿼리 분리)에서 파생됩니다.

명령어는 스테이트를 변환하며 집약 루트 또는 엔티티에서의 메서드 호출과 거의 동일합니다.쿼리는 상태를 읽지만 변환하지는 않습니다.

CQRS는 도메인 구동 설계를 필요로 하지 않지만 집약 루트의 개념을 사용하여 명령어와 쿼리를 명확하게 구분합니다.즉, 특정 집약 루트에 명령어에 대응하는 메서드가 있고 명령어핸들러가 집약 루트에서 메서드를 호출하는 것입니다.

집약 루트는 작업의 로직을 수행하고 다수의 이벤트나 장애 응답 또는 데이터 저장소에 쓸 수 있는 자체 상태를 변환하는 역할을 합니다.명령어 핸들러는 집약 루트 상태 저장 및 필요한 컨텍스트 작성(예: 트랜잭션)과 관련된 인프라스트럭처 문제를 가져옵니다.

이벤트 소싱

이벤트 소싱은 엔티티가 직접 직렬화 또는 객체 관계 매핑을 통해 내부 상태를 추적하지 않고 이벤트를 읽고 이벤트 저장소에 커밋하는 아키텍처 패턴입니다.

이벤트 소싱이 CQRS 및 도메인 구동 설계와 결합되어 있는 경우 집약 루트는 명령어 검증 및 적용(대개 명령어핸들러에서 인스턴스 메서드를 호출함으로써) 및 이벤트 퍼블리시를 담당합니다.또한 이는 집약체가 메서드 호출을 처리하기 위한 논리의 기초가 되는 기초이기도 합니다.따라서 입력은 명령어이고 출력은 이벤트스토어에 저장되는 하나 이상의 이벤트이며, 그 후 종종 관심 있는 사용자(응용 프로그램 뷰 등)를 위해 메시지브로커에 게시됩니다.

aggregate 루트를 출력 이벤트에 모델링하면 표준 n계층 데이터 전달 아키텍처와 같이 엔티티에서 읽기 데이터를 투영할 때보다 내부 상태를 더욱 격리할 수 있습니다.중요한 이점 중 하나는 집합 루트가 내부 상태를 포괄적으로 감추기 때문에 자명한 정리 프로버(Microsoft 계약[9] 및 체스)를 적용하기가 더 쉽다는 것입니다.이벤트는 애그리게이트 루트 인스턴스의 버전을 기반으로 유지되는 경우가 많아 최적의 동시성을 통해 분산 시스템에서 동기화하는 도메인 모델을 생성합니다.

주목할 만한 도구

도메인 중심 설계는 특정 도구나 프레임워크에 의존하지 않지만 다음과 같은 중요한 예가 있습니다.

  • Actifsource는 Eclipse용 플러그인으로서 DDD와 모델 구동 엔지니어링 및 코드 생성을 결합한 소프트웨어 개발을 가능하게 합니다.
  • Cubic Web은 데이터 모델에 의해 완전히 구동되는 오픈 소스 시멘틱 웹 프레임워크입니다.높은 수준의 지침을 통해 데이터 모델을 반복적으로 세분화할 수 있습니다. 릴리즈 후 출시됩니다.데이터 모델을 정의하면 기능하는 웹 애플리케이션을 얻을 수 있습니다.기본 보기가 충분하지 않을 때 데이터가 표시되는 방법을 정의하려면 추가 작업이 필요합니다.
  • OpenMDX는 Java SE, Java EE 및 를 지원하는 오픈 소스 Java 기반 MDA 프레임워크입니다.NET. OpenMDX는 "모델을 사용하여 운영 체제의 런타임 동작을 직접 구동"한다는 점에서 일반적인 MDA 프레임워크와 다릅니다.
  • Restful Objects: Restful API를 도메인 개체 모델(도메인 개체가 엔티티, 뷰 모델 또는 서비스를 나타낼 수 있음)에 매핑하기 위한 표준입니다.2개의 오픈소스 프레임워크(1개는 Java, 1개는 for)NET)는 리플렉션을 사용하여 도메인 모델에서 자동으로 Restful Objects API를 생성할 수 있습니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ Millet, Scott; Tune, Nick (2015). Patterns, Principles, and Practices of Domain-Driven Design. Indianapolis: Wrox. ISBN 978-1-118-71470-6.
  2. ^ Vernon, Vaughn (2013). Implementing Domain-Driven Design. Upper Sadle River, NJ: Addison-Wesley. p. 3. ISBN 978-0-321-83457-7.
  3. ^ 를 클릭합니다Domain driven design.
  4. ^ Microsoft Application Architecture Guide, 제2판http://msdn.microsoft.com/en-us/library/ee658117.aspx#DomainModelStyle 에서 취득했습니다.
  5. ^ a b Evans, Eric (2004). Domain-Driven Design: Tackling Complexity in the Heart of Software. Boston: Addison-Wesley. ISBN 978-032-112521-7. Retrieved 2012-08-12.
  6. ^ 를 클릭합니다Haywood, Dan (2009), Domain-Driven Design using Naked Objects, Pragmatic Programmers.
  7. ^ MDE는 MDA의 슈퍼셋으로 간주할 수 있습니다.
  8. ^ Cabot, Jordi (2017-09-11). "Comparing Domain-Driven Design with Model-Driven Engineering". Modeling Languages. Retrieved 2021-08-05.
  9. ^ MS 버그 검출 도구

외부 링크