도메인 이해 및 팀 구축: 변화의 기초(II)

복잡한 프로젝트를 시작하려면 포괄적인 맥락 수집이 필요하며 동시에 도메인 전문가의 통찰력을 활용하여 새로운 관점에서 도메인 지식에 접근해야 합니다. 이 접근 방식은 기술 팀을 비즈니스 목표에 맞춰 조정하고 제품 수명 주기 전반에 걸쳐 정보에 입각한 의사 결정을 위한 기본 로드맵을 설정합니다.

이전 팀 및 현재 애플리케이션 사용자와의 초기 지식 수집 세션은 비생산적인 것으로 나타났습니다. 우리는 내재된 위험에도 불구하고 독립적으로 진행하는 것을 잠시 고려했습니다.

이벤트스토밍: 도메인 공개

저는 기술 책임자로서 프로젝트의 복잡성과 팀의 소유권 요구를 고려하여 처음부터 도메인 중심 접근 방식을 옹호했습니다. 이는 도메인을 중심으로 의사소통을 간소화하고 애플리케이션의 현재 상태 매핑을 촉진하는 공유 이해(유비쿼터스 언어)를 조성했습니다.

Miro 템플릿을 사용하여 EventStorming 세션을 시작하여 효과적인 집중을 위한 구조와 범례를 제공했습니다. 사전 세션 준비 또는 초기 설명을 통해 EventStorming 개념을 사전에 숙지하는 것은 매우 유익합니다.

구조화된 EventStorming 프로세스는 다음과 같이 구성됩니다.

1. 도메인 이벤트 탐색(큰 그림): 도메인 전문가와 함께 주요 시스템 이벤트를 식별하고 시간순으로 정렬하고 검증하여 격차와 종속성을 강조합니다.
2. 정밀화 및 분석: 설명 메모 추가, 질문 문서화, 각 이벤트 심층 분석, 중요한 결정 사항 파악
3. 도메인 모델링: 집계 및 경계 식별, 행위자 및 역할 정의, 트리거 명령 설정, 정책 및 비즈니스 규칙 문서화, 내부/외부 이벤트 트리거 식별
4. 문서화 및 검증: 수집된 정보를 정리 및 정리하고, 명확한 관계를 구축하고, 이해관계자와 모델을 검증하고, 참조 문서를 생성합니다.

EventStorming은 도메인 이해뿐만 아니라 도메인 기반 디자인(DDD) 원칙을 전략적, 전술적으로 적용할 수 있는 기반을 제공했습니다.

전략적 도메인 중심 디자인

중요한 초기 단계에는 도메인을 전략적으로 구성하는 것이 포함되었습니다. 시스템의 복잡성과 기술/비즈니스 조정의 필요성으로 인해 DDD 원칙을 채택하게 되었습니다. 컨텍스트 매핑은 리팩토링을 기다리는 모놀리스 내에서도 매우 귀중한 것으로 입증되었습니다. 우리는 공유 커널을 사용하여 단일 기술 컨텍스트 내에서 작동하는 제한된 컨텍스트를 식별했습니다. 이 분석은 깊이 탐구되지는 않았지만 프로젝트를 도메인 중심 아키텍처로 안내하여 기술 개발과 팀 간 협업을 모두 개선했습니다.

경계 정의(제한된 컨텍스트)

제한된 컨텍스트를 식별하여 시스템 간 및 외부 시스템 관계를 명확히 하고 복잡성을 단순화하며 향후 모듈화를 위한 기반을 구축했습니다. 이러한 초기 결정은 모놀리스를 정의된 컨텍스트에 맞춰 관리 가능한 구성 요소로 분해하는 데 도움이 됩니다. 이는 또한 단순화, 분리 또는 제거를 위한 영역의 우선순위 지정 및 식별을 촉진했습니다. 우리는 외부 시스템 상호 작용을 위해 부패 방지 계층(ACL)을 구현하고 시스템 무결성을 유지하는 데 중점을 두었습니다.

5가지 핵심 맥락이 확인되었습니다.

• 주문 할당
• 라벨 생성
• 주문 준비
• 전자상거래 통합
• 대량주문 준비

이러한 결정은 지속 가능한 아키텍처를 육성하고 비즈니스 요구에 맞춰 개발을 조정했습니다.

유비쿼터스 언어

강력한 유비쿼터스 언어를 구축하는 것이 중요하다는 것이 입증되었습니다. 도메인 전문가와 개발자의 협업을 통해 만들어지는 공유 언어의 이점은 번역 노력이나 잘못된 해석보다 훨씬 큽니다. 이 살아있는 리소스는 기술팀을 도메인 전문가와 연결하여 의사소통을 개선하고 오해를 줄이고 코드에서 정확한 도메인 표현을 보장합니다. 이를 통해 효율적이고 비즈니스에 맞는 기술 솔루션이 조성되었습니다.

전술적인 도메인 중심 디자인

전략적 프레임워크에 따라 전술적 DDD 원칙을 구현하여 코드를 구조화하고 도메인 현실을 반영하며 장기적인 지속 가능성을 보장했습니다.

엔티티 및 값 개체

엔티티와 값 개체의 차이점을 이해하는 것이 중요합니다.

엔티티

엔티티는 속성이 변경되더라도 고유하고 지속적인 ID를 보유합니다. 예는 다음과 같습니다.

• 주문
• 제품
• 캐리어
• 쇼핑
• 고객

값 개체

가치 객체에는 개별 정체성이 부족합니다. 그들의 가치가 그들을 정의합니다. 동일한 속성은 동등함을 의미합니다. 이는 불변이며 도메인 전체에 나타나는 개념을 캡슐화하는 데 이상적입니다. 예는 다음과 같습니다.

• 제품참조
• 프로덕트Ean13
• 주문참고
• 가격
• 무게
• 배송번호

이러한 접근 방식을 통해 책임이 명확하게 정의된 더욱 이해하기 쉬운 모듈식 코드가 생성되었습니다.

값 개체 예시:

<?php
readonly class ProductEan13
{
    public string $value;

    public function __construct(string $value)
    {
        $pattern = '/^\d{13}$/';
        if (!preg_match($pattern, $value)) {
            throw new \Exception('Invalid product Ean13');
        }
        $this->value = $value;
    }
}

서비스

서비스는 목적과 구현 패턴에 따라 분류됩니다.

도메인 서비스

도메인 서비스는 엔터티나 값에 맞지 않는 비즈니스 논리를 캡슐화하여 인프라 종속성 없이 도메인 규칙 내에서 엄격하게 작동합니다.

<?php
readonly class ProductEan13
{
    public string $value;

    public function __construct(string $value)
    {
        $pattern = '/^\d{13}$/';
        if (!preg_match($pattern, $value)) {
            throw new \Exception('Invalid product Ean13');
        }
        $this->value = $value;
    }
}

응용서비스

애플리케이션 서비스는 외부 상호 작용을 통해 도메인 운영을 조정하고 복잡한 운영을 중앙 집중화하며 도메인과 인프라를 분리합니다. 여기에는 사용 사례, 명령 처리기 및 이벤트 처리기가 포함됩니다.

인프라 서비스

인프라 서비스는 외부 구성 요소 상호 작용(데이터베이스, 파일 시스템 등)을 처리하고 도메인 불가지론을 유지하기 위한 어댑터 역할을 합니다.

<?php
class CheapestCarrierGetter
{
    public function get(
        DeliveryOptionCarrierCollection $deliveryOptionCarriers,
        Weight $orderWeight,
        Country $country,
        PostalCode $postalCode,
        bool $isCashOnDelivery = false,
    ): Carrier {
        // Logic to get the cheapest carrier
    }
}

서비스 분류

서비스는 Transformers, Builders, Factory, Presenters, Notifiers, Validators, Clients 등 기능 및 관련 디자인 패턴별로 분류됩니다.

이 초기 도메인 모델링은 불완전하고 반복적이었지만 팀 참여와 헌신을 촉진했습니다. 추가적인 개선과 구조조정이 예상되었습니다.

권장 DDD 리소스:

• Eric Evans의 "도메인 중심 설계: 소프트웨어 중심의 복잡성 다루기"
• Vaughn Vernon의 "도메인 기반 디자인 구현"
• Carlos Buenosvinos, Christian Soronellas, Keyvan Akbary의 "PHP를 사용한 도메인 기반 디자인"

팀 구성: Tuckman의 스테이지

DDD 채택은 Tuckman의 단계(Forming, Storming, Norming, Performing)에 따라 팀 구성을 병행했습니다.

성형

초기 팀 구성원은 프로젝트를 검토하고 운영을 문서화했으며 기술 및 조직 기반(프로세스, 표준, 도구)을 확립했습니다.

폭풍

사소한 의견 차이로 인해 업무 스타일, 의사소통 방식, 의사결정 과정이 결정되었습니다.

노밍

팀 계약, 코딩 표준, 개발 프로세스, WIP 제한, 배포 규칙, 기술 부채 관리 및 ADR이 설정되었습니다.

공연

정립된 프레임워크를 통해 효율적인 제품 개발, 가치 있는 이니셔티브의 우선순위 지정, 지속적인 개선 문화 조성이 가능해졌습니다.

문서: Diátaxis 모델

문서는 Diátaxis 모델(튜토리얼, 가이드, 설명 및 참조)에 따라 GitLab Pages 및 Jekyll과 Just the Docs 테마를 사용하여 관리되었습니다. Event Catalog 및 AsyncAPI를 사용한 문서화 자동화가 계획되었지만 완전히 구현되지는 않았습니다.

위 내용은 도메인 이해 및 팀 구축: 변화의 기초(II)의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!