PHP의 DDD에 대해 이야기합시다

DDD는 "Domain Driven Design"의 약어로, 중국어로 도메인 중심 디자인(Domain Driven Design)으로 번역되는 경우가 많습니다. 오늘은 PHP에서 DDD를 소개하겠습니다. 필요하다면 참고하시면 됩니다.

DDD란 무엇인가(우선 무엇이 아닌가)

DDD는 Domain Driven Design의 약어로, 중국어로 Domain-Driven Design으로 번역되는 경우가 많다. DDD가 무엇인지 이해하기 전에 먼저 DDD가 아닌 것이 무엇인지 논의해 보겠습니다.

• DDD ​​​​는 소프트웨어 프레임워크가 아닙니다. 그러나 DDD를 기본 아이디어로 사용하여 Java로 구현된 마이크로서비스 소프트웨어 프레임워크인 Axon과 같은 DDD 아이디어를 기반으로 한 프레임워크가 존재합니다.

• DDD는 소프트웨어 디자인 패턴이 아닙니다. 팩토리나 싱글톤과 같은 디자인 패턴이 아닙니다. 그러나 DDD 사고에서는 Repository와 같은 디자인 패턴이 제안됩니다.

• DDD ​​​​는 시스템 아키텍처 패턴이 아닙니다. MVC와 같은 아키텍처 패턴이 아닙니다. 그러나 DDD 아이디어에서는 이벤트 소싱(Event Sourcing) 및 읽기-쓰기 격리(Command Query Responsibility Segregation)와 같은 아키텍처 패턴을 제안했습니다.

그럼 DDD란 정확히 무엇인가요?

소프트웨어는 인간에게 봉사하고 인간의 생산성을 향상시키기 위해 만들어진 도구입니다. 예를 들어, CRM은 고객 데이터 관리에 중점을 두고 판매자가 고객과 연락을 유지하는 데 도움이 되는 도구입니다.

소프트웨어의 본질은 컴퓨터에서 실행되는 코드입니다. 추상적인 코드를 인간의 관심 분야에 보다 정확하게 매핑하는 방법은 함수형 프로그래밍(FP)이든 객체 지향이든 소프트웨어 개발자가 탐구해 온 주제입니다. 프로그래밍(OOP)은 개발자가 해당 분야에 더 관련성이 높은 소프트웨어 모델을 개발하도록 돕는 것입니다.

기존 소프트웨어 개발 방법에서는 소프트웨어 품질에 영향을 미치는 일련의 기술적, 비기술적 문제에 자주 직면합니다.

• 개발자는 기술에 관심이 있지만 디자인과 비즈니스 사고가 부족합니다. 개발자들은 비즈니스 요구 사항을 완전히 이해하지 못한 채 비밀리에 작업하며, 기능이 온라인에 제공되더라도 아무도 그 기능에 관심을 두지 않습니다.

• 비즈니스 입력 대신 코드 입력. 기술진은 기술 구현에 대한 특별한 호감을 갖고 있어 굳이 닭을 죽이기 위해 굳이 쇠칼을 사용할 필요가 없는 상황이 벌어지고 있다.

• 데이터베이스를 너무 강조합니다. 비즈니스보다는 데이터베이스 설계에 중점을 둔 개발로 인해 소프트웨어가 끊임없이 변화하는 비즈니스 로직에 적응하지 못하는 경우가 많습니다.

DDD는 도메인(비즈니스)에서 시작하여 소프트웨어 모델링의 복잡성을 해결하는 것을 목표로 하는 디자인 아이디어입니다. 모델링 방법론으로도 이해할 수 있습니다.

DDD의 디자인 철학은 전략과 전술의 두 부분으로 나뉩니다.

전략적 디자인은 거시적 디자인으로 이해할 수 있습니다. 그 목적에는 비즈니스의 복잡성 분석, 비즈니스 범위 분할, 비즈니스 통합 방법 안내 등이 포함됩니다. 전술적 디자인은 비즈니스 로직을 구현하기 위한 일련의 도구를 제공하는 마이크로 레벨(코드 레벨) 디자인으로 이해할 수 있습니다.

Strategic Design

Universal Language (Ubiquitous Language)

언어는 인간의 의사소통을 위한 기본 도구입니다. 그러나 개발자는 기술적인 용어와 도메인 전문가를 사용하는 데 익숙합니다. (여기서 도메인 전문가는 일반적으로 비즈니스 등에 능숙한 전문가를 말합니다. 사용자 및 고객) 등)은 기술적 용어에 대한 관심이 없으므로 필연적인 의사소통 문제가 발생합니다. 일단 의사소통 문제가 발생하면 개발된 소프트웨어가 도메인 전문가의 실제 문제점을 해결하기 어려울 것입니다.

보편적 언어는 DDD 사고의 초석입니다. 개발자와 도메인 전문가가 공동으로 만드는 커뮤니케이션 언어로, 팀 구성원이 보편적인 언어를 사용하여 장벽 없이 소통할 수 있습니다.

이를 위해서는 개발자가 기술 전문 용어를 버리고, 도메인 전문가와 협력하고, 도메인 전문가와 같은 비즈니스 문제에 집중하고, 비즈니스 용어를 공동으로 발굴하고 다듬고, 공통 언어를 만들어야 합니다.

범용 언어는 코드에 직접 적용할 수 있는 경우가 많습니다. 클래스 또는 클래스의 메서드로 직접 작성할 수 있습니다.

예를 들어 장바구니를 개발할 때 기술적인 용어를 사용하는 대신

• Cart::create(): 장바구니를 만듭니다.

• Cart::updateStatus(): 장바구니 상태를 업데이트합니다.

• Cart::remove(): 장바구니를 제거합니다.

비즈니스에 더 가까운 공통 언어를 사용하는 것이 좋습니다.

• Cart::init(): 장바구니를 만듭니다.

• Cart::addItemToCart(): 항목을 추가합니다.

• Cart::removeItemFromCart(): 항목을 제거합니다.

• Cart::empty(): 장바구니를 비웁니다.

후자를 사용할 경우 개발자는 각 수업 방법의 의미를 설명할 필요가 없으며 도메인 전문가는 각 수업 방법의 목적을 직접 이해할 수 있습니다. 개발자는 도메인 전문가와 함께 코드 작업을 통해 비즈니스 프로세스를 개선할 수도 있습니다.

Bounded Context

범용 언어 자유를 실현한 후에는 제한된 컨텍스트를 사용하여 각 범용 언어 집합의 사용 경계를 지정해야 합니다. 제한된 컨텍스트는 의미론과 컨텍스트 사이의 경계입니다. 즉, 각 개념은 제한된 컨텍스트에서 고유하며 다의어는 허용되지 않습니다.

간단한 예를 들어 제한된 컨텍스트를 설명할 수 있습니다. 예를 들어 장바구니의 제한된 컨텍스트에서는 사용자라는 단어를 사용하여 제품을 구매한 고객을 나타낼 수 있습니다. 등록 시스템에서는 사용자라는 단어를 사용하여 사용자 이름과 비밀번호가 있는 계정을 나타낼 수 있습니다. 단어는 동일하지만 서로 다른 제한된 맥락에서 서로 다른 의미를 갖습니다.

우리는 제한된 컨텍스트와 범용 언어를 사용하여 언어 수준에서 비즈니스를 분할합니다. 제한된 컨텍스트는 도메인의 각 요소에 명확한 개념을 제공합니다. 개발자는 마음 속에 하나의 요소를 지원하는 여러 개념을 플래시할 수밖에 없으며 "큰 진흙 덩어리" 코드 작성을 피할 수 있습니다.

Subdomain

바운드 컨텍스트가 비즈니스를 언어 수준에서 분할하는 것이라면 하위 도메인은 비즈니스의 비즈니스 가치를 분할하는 것입니다. 모든 비즈니스에는 고유한 초점이 있습니다. 전자상거래 플랫폼이 동일해 보이더라도 Taobao는 개방형 플랫폼 모델이고 JD.com은 가치 사슬 통합 모델입니다. 한 가지 분명한 차이점은 JD가 타사 물류를 사용한다는 것입니다. com은 자체 물류 시스템을 구축합니다.

그렇다면 개발자로서 왜 자신과 관련이 없어 보이는 비즈니스 모델에 관심을 가져야 합니까? 반대로, 비즈니스의 구조를 이해해야만 비즈니스의 빠른 발전을 지원하기 위한 명확한 우선순위를 가진 시스템을 개발할 수 있습니다.

하위 도메인은 우선순위를 정하는 데 도움이 되는 도구입니다.

하위 도메인에는 세 가지 유형이 있습니다.

• 코어 도메인: 시스템에서 가장 많은 투자가 필요한 영역으로 전체 비즈니스의 핵심 경쟁력을 나타냅니다. 기업의 생존과 직결되는 핵심 영역을 다듬기 위해서는 많은 자원과 자원을 투자해야 합니다. 예를 들어 JD.com의 자체 구축 물류 시스템이 있습니다.

• 지원 도메인: 이 도메인은 기업의 핵심 사업은 아니지만 핵심 도메인은 아웃소싱 맞춤형 솔루션을 사용하여 구현할 수 있습니다. 예를 들어 인증 컨텍스트 및 권한 컨텍스트가 있습니다.

• 일반 도메인: 성숙한 솔루션이 있는 경우 일반 도메인은 기성 솔루션을 구매할 수 있습니다. 그렇지 않은 경우 아웃소싱을 사용할 수도 있습니다. 일반 도메인에 대한 투자는 최소화되어야 합니다. 예를 들어 Taobao의 경우 물류는 일반적인 영역입니다.

제한된 컨텍스트와 하위 도메인의 관계에 대해 다른 의견이 있습니다. 일부 전문가는 1:1을 옹호하는 반면 다른 전문가는 1:N을 옹호합니다. 개인적으로 저는 1:1을 옹호합니다. 왜냐하면 저는 Implementing Domain-Driven Design이라는 책의 저자로부터 깊은 영향을 받았기 때문입니다.

컨텍스트 매핑

거대한 시스템에서는 제한된 컨텍스트 간에 특정 종속성이 있어야 합니다. 한 컨텍스트에서 다른 컨텍스트로 개념을 어떻게 매핑합니까? 우리는 컨텍스트 매핑을 사용합니다.

다음은 컨텍스트 매핑의 여러 관계 유형입니다.

• 파트너십

• 공유 커널

• 고객-공급업체 개발

• Conformist

• An ticorruption Layer

• 호스트 서비스 공개

• 게시된 언어

• SeparateWay

• Big Ball of Mud

위는 상대적으로 추상적인 개념이며 때로는 두 개의 제한된 컨텍스트 사이에 여러 관계가 있을 수 있습니다.

위는 DDD 전략 설계의 몇 가지 핵심 개념입니다.

전술적 디자인

제한된 맥락에서 개념을 모델링하는 방법은 DDD에서 제공하는 전술적 디자인을 사용하겠습니다.

Entity

우선 엔터티에 대해 이야기하겠습니다.

엔티티는 도메인에 있는 독립적인 사물의 모델입니다. 각 엔터티에는 ID, UUID, 사용자 이름 등과 같은 고유 식별자가 있습니다. 대부분의 경우 엔터티는 변경 가능하며 시간이 지남에 따라 상태가 변경됩니다. 그러나 엔터티가 반드시 변경 가능해야 하는 것은 아닙니다.

단체의 가장 큰 특징은 개성과 독창성입니다. 예를 들어, 간단한 장바구니의 컨텍스트에서 주문은 엔터티이고 ID는 식별자이며 상태는 접수, 확인, 환불 사이에서 변경될 수 있습니다.

값 개체

값 개체는 현장의 엔터티를 설명, 수량화 또는 측정하는 데 사용되는 모델입니다. 엔터티와 달리 값 개체에는 고유 식별자가 없으며 두 개의 동등한 값 개체는 상호 교환 가능합니다. 값 개체는 불변성을 가집니다. 일단 생성되면 값 개체의 속성이 확정되며 변경할 수 없습니다.

가치 대상을 이해하는 가장 직접적인 방법은 일상 생활에서 A의 10위안과 B의 10위안이 동등하게 교환될 수 있는 지폐를 상상하는 것입니다.

위의 장바구니 컨텍스트에서 금액(Money)은 값 개체이며 금액은 통화와 금액으로 구성됩니다.

class Money {
  public $currency;
  public $amount;

  function __construct($currency, $amount) {
    $this->currency = $currency;
    $this->amount = $amount;
  }  
}

모델링에 값 개체를 사용하면 코드를 사용하여 도메인 모델을 보다 정확하게 구축하는 데 도움이 될 수 있습니다.

집계

집계란 무엇인가요? 집계는 컨텍스트에 따라 비즈니스 영역을 보다 세밀하게 구분한 것이며, 각 집계는 자체 비즈니스 일관성을 보장합니다.

그렇다면 비즈니스 불변성이란 무엇일까요? 비즈니스 불변성은 비즈니스 영역에서 위반할 수 없는 비즈니스 규칙을 나타내며 일관성이 보장되어야 합니다. 예를 들어, 주문을 환불할 때 환불 금액은 지불한 금액을 초과할 수 없습니다.

집계의 구성 요소는 엔터티와 값 개체이며 엔터티만 있는 경우도 있습니다. Aggregate의 비즈니스 일관성을 보호하기 위해 각 Aggregate는 Aggregate Root라고 하는 특정 엔터티를 통해서만 운영될 수 있습니다.

도메인 이벤트

도메인 이벤트는 공통 언어를 통해 분석되는 이벤트로, 일반적인 거래 이벤트와 달리 비즈니스와 밀접한 관련이 있으므로 네이밍에 비즈니스 명사가 포함되는 경우가 많아 데이터베이스와 연결해서는 안 됩니다. 예를 들어 장바구니에 제품을 추가할 때 해당 도메인 이벤트는 CartUpdated가 아니라 ProductAddedToCart여야 합니다.

요약

DDD는 또한 글의 시작 부분에서 언급한 이벤트 소싱, 육각형과 같은 아키텍처 패턴도 제안합니다.

DDD의 핵심은 비즈니스 관점에서 소프트웨어 모델을 구축하는 것입니다. 그 목적은 비즈니스에 더 가까운 코드를 작성하고 코드에서 비즈니스 프로세스를 보다 직관적으로 명확하게 하는 것입니다. 그러나 DDD를 실현하는 것은 하루아침에 이루어지는 것이 아닙니다. 지속적인 연습과 연마가 필요합니다.

추천 학습: php 비디오 튜토리얼

위 내용은 PHP의 DDD에 대해 이야기합시다의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!