폰로봇팀의 DDD 실습

소개

DDD ​​​​는 방법론의 집합이자 아이디어의 집합입니다. 다양한 메타모델과 명목상 개념. 그들의 본질은 지도 이념에 부합하는 해결 방법 중 "하나"이며, 초보자는 겉모습에 쉽게 함정에 빠지게 됩니다. "모든 DDD 메타모델은 실제 개발에서 특정 유형의 문제를 해결하기 위해 만들어졌다"는 점을 항상 명확하게 이해해야 합니다. 다양한 메타 모델을 접할 때 자신의 비즈니스가 직면한 문제를 기반으로 검증을 수행해야 개념적 표현에 갇히지 않고 문제 해결의 본질로 돌아갈 수 있습니다.

배경

데이터 아키텍처 팀은 2018년부터 비즈니스 요구에 따라 휴대폰 로봇 개발을 시작했는데, 눈 깜짝할 사이에 거의 5년이 지났습니다. 현재 이 플랫폼에는 하루 수십만 건의 아웃바운드 통화를 통해 회사의 딜러, 중고차, OEM, 금융 및 기타 BU 비즈니스에 아웃바운드 통화 기능을 제공하기 위해 100개 이상의 다양한 유형의 로봇이 구축되었습니다. 스마트폰 로봇 프로젝트는 형태를 갖추기 시작했지만 그 과정에서 많은 어려움도 겪었습니다. 이러한 과제에 대처하기 위해 우리 팀은 마침내 재건과 개발에 DDD 사고를 채택했습니다.

DDD를 적용하는 과정에서 데이터 아키텍처 팀은 자체 개발 사양 중 일부를 구현했습니다. 여기서 저는 몇 가지 경험과 아이디어를 여러분과 공유하고 그것이 출발점이 될 수 있기를 바랍니다. 여기서는 설명하겠습니다. 이 기사에서는 많은 다변량 모델이 논의되지 않으며 특정 사례가 제공되지 않습니다. 먼저 길이 문제를 고려하십시오. 두 번째는 DDD 아이디어를 이해하고 각 사업을 결합하여 구현하는 것입니다. 내 사업에서 예를 드는 것은 의미가 없습니다. 게다가 이런 사례도 쉽게 찾아볼 수 있다. 동시에 우리 팀이 직면한 문제와 해결책, 구현 프로세스 및 우리가 구성한 개발 사양을 모든 사람이 공유하는 것이 더 가치 있다고 생각합니다. DDD에 관심이 있거나 이 기사에 대해 더 알고 싶거나 질문이 있는 학생들은 저에게 연락하여 토론을 할 수 있습니다.

아래에서는 로봇 프로젝트에서 직면한 과제, DDD가 DDD인 이유, DDD 구현 단계, 팀 개선, 이론에서 실제까지 겪게 되는 갈등, 향후 DDD 애플리케이션 개선 및 결론 등의 부분을 공유하겠습니다.

1. 직면한 과제

도전 과제 1: 비즈니스 로직은 매우 복잡합니다. 다양한 서비스에 액세스하면 다양한 시나리오에서 특정 서비스를 처리하기 위해 새로운 논리가 지속적으로 추가됩니다.

예: 프로세스의 의도 인식 논리.

의도 인식을 위해서는 AI의 여러 모델을 인식해야 합니다. 여러 모델에서 인식된 의도는 충돌할 수 있으며, 충돌하는 의도 구성 규칙 중에서 선택해야 합니다. 동시에 일부 콜드 스타트 ​​또는 긴급 최적화 시나리오의 경우 실시간으로 적용되도록 규칙을 구성하여 의도 식별을 지원해야 합니다. 그리고 규칙의 의도 인식에서는 일치하는 단어 슬롯이 지원되어야 합니다. 단어 슬롯에는 다양한 유형이 있습니다. 시나리오가 포함된 전역 단어 슬롯과 프로세스가 포함된 단어 슬롯은 우선순위에 따라 구분됩니다. 데이터 식별의 원천은 AI가 식별한 것, 사전적 규칙에 의해 일치된 것, 비즈니스 당사자가 전달한 것 등으로 나눌 수 있습니다. 일정 기간 동안 사업이 수행된 후에는 다양한 유형의 슬롯에 다양한 속성이 추가됩니다. 예를 들어 자동차 시리즈의 슬롯에는 제품, 사업 범위, 비운영 등이 포함됩니다.

과제 2: 코드 아키텍처 구조가 명확하지 않습니다. 비즈니스 요구 사항이 추가되면 코드 크기가 늘어납니다. 논리의 복잡성과 팀 개발자의 다양한 코드로 인해 다양한 논리 경계가 점차 혼란스러워지고 있습니다.

예: 우리의 일반적인 개발 방법은 기능 모듈에 따라 분해하고 비즈니스 프로세스를 직렬로 연결하여 각 모듈을 조정하여 비즈니스 요구 사항을 공동으로 완료하는 것입니다. 그러나 이러한 유형의 비즈니스의 복잡한 논리를 처리할 때 이 솔루션 설계는 큰 단점이 있으며 모듈 경계가 쉽게 침투됩니다.

모듈 간의 관계는 서로를 호출합니다. 모듈의 원래 격리 설계는 실제로 구현 과정에서 완전히 깨졌습니다. 원래 이상적인 수직 분할 모듈은 메시형 구조가 됩니다.

중간 링크의 모듈 리더가 개발한 속성이나 메소드는 다른 외부 모듈에 종속되어 기능이 분기됩니다. 이로 인해 나중에 요구사항이 변경될 때 위험이 커지거나, 마음대로 변경할 수 있는 메서드를 변경할 수 없으며 이를 구현하려면 추가적인 논리 코드를 추가해야 하는 경우도 있습니다. 이는 이미 복잡한 코드를 더욱 복잡하게 만듭니다.

비즈니스 요구 사항을 해체하는 것은 불합리합니다. 구현 시 필요한 기능이 근처에 개발되고, 모듈의 해체가 엄격하게 준수되지 않으며, 지침으로 통일된 사고가 부족합니다.

챌린지 3: 제품에 대한 수요가 많고, 실제 가치가 있는지 판단하기 어렵습니다.

도전 4: 로직은 빠르게 변화하며 많은 요구 사항에 따라 코드 로직 재설계가 필요합니다.

챌린지 5: 업체가 많고, 업체별로 설명이 일관되지 않으며, 통신 비용이 많이 듭니다.

수직적 경계가 무너지고, 코드 복잡성이 증가하며, 비즈니스 프로세스가 자주 조정됩니다. 이러한 여러 차원이 서로 중첩되어 개발 및 유지 관리가 기하급수적으로 더 어려워집니다. 전화로봇의 1차 응용시스템의 안정성은 보장하기 어렵다. 기술 동급생이 모두 수석 엔지니어라고 해도 그들은 이해할 수 있는 마이크로서비스 아이디어에 따라 설계하고 모듈에 따라 프로젝트를 분해했습니다. 코드 로직이 구축하고 확장하기 위해 많은 설계 패턴을 인용했더라도 연결되어 있었습니다. 회사의 다양한 부분, 플랫폼 품질 도구, 많은 단위 테스트를 작성했습니다. 그러나 프로젝트가 새로운 요구 사항에 대해 반복될 때 여전히 많은 "놀라움"이 나타나 전체 팀에 골치 아픈 문제를 안겨주었습니다.

2. 왜 DDD

왜 DDD인가요? 매일 수많은 기술 스택과 수많은 아이디어가 있는데, 이를 처리하기 위해 DDD를 사용하는 이유는 무엇입니까? 우선 DDD는 "소프트웨어의 핵심 복잡성을 처리하는 방법"을 매우 잘 수정하여 많은 사람들이 알고 싶어하게 만듭니다. 그럼 DDD가 프로젝트에서 직면한 과제를 어떻게 해결하는지 살펴보겠습니다.

먼저 DDD의 복잡성 분류를 살펴보고 DDD가 처리해야 하는 복잡성이 내가 직면한 과제인지 알아보겠습니다. DDD 관련 자료에서는 이해능력과 예측능력이라는 두 가지 차원에서 복잡성의 원인을 탐색하고 분석한다.

이해 능력(즉, 소프트웨어 시스템은 복잡하고 개발자가 이해하기 어렵습니다):

첫 번째 척도: 이해 능력에 영향을 미치는 첫 번째 요소입니다. 수억 줄의 코드가 있으며 각 수요 지점 간의 관계는 서로 영향을 미칩니다. 한 부분을 수정하면 몸 전체에 영향을 미칩니다.

두 번째 구조: 불합리하거나 심지어 혼란스러운 구조는 개발자가 기능을 유지하기 어렵게 만듭니다.

예측 능력(즉, 사업 전개를 예측하기 어렵다):

요구 사항이 변경되면 소프트웨어 구현 방향을 예측하기 어렵고 과잉 설계 및 과소 설계 문제가 발생합니다. 과도한 설계로 인해 많은 인터페이스가 예약되었고, 코드의 구현 복잡성을 높이기 위해 많은 패턴이 구성되었지만 나중에 사용되지 않은 것으로 확인되었습니다. 디자인이 부족하고, 요구사항 구현 시 이후 개발이 고려되지 않으며, 변경 사항이 발생하면 기존 디자인을 뒤집어서 재개발해야 하는 경우가 많습니다.

DDD의 복잡성 원인은 규모, 구조, 변화로 요약됩니다. 규모와 구조는 이해에 장애물을 만들고, 변화는 예측에 장애물을 만들고, 두 가지가 합쳐져 ​​복잡성 문제를 형성합니다.

둘째, DDD는 코드 설계 단계의 이론일 뿐만 아니라 요구 사항 분석, 아키텍처 매핑, 모델링 및 구현에 이르는 전체 프로세스 설계 지침도 포함합니다.

수요 분석 단계에서는 관련 지도 이념을 통해 비즈니스 가치를 사전에 정확하게 파악하고 향후 변화 방향을 포착할 수 있습니다. 아키텍처 매핑 단계에서는 요구사항부터 아키텍처까지의 과정을 지도하는 이념이 주어지고, 설계 가중치와 사양이 추가된다. 하위 도메인 분할, 시스템 계층화 및 제한된 컨텍스트 비즈니스 분류를 통해 시스템 아키텍처의 명확성을 보장하고 시스템 복잡성을 줄이기 위한 지침 사양을 제공합니다. 모델링 및 구현 단계에서는 도메인 중심의 디자인 관련 메타 모델을 제시하여 각 부분의 기능적 구분을 명확하게 하고, 비즈니스 요구 및 향후 기능 변화에 신속하게 대응할 수 있도록 합니다.

다시 한 번 DDD가 제시한 지침 이념을 살펴보겠습니다.

규모 ​​문제: 경계 허물기. 하위 도메인과 제한된 컨텍스트를 통해 디스어셈블리를 분할하고 정복하세요.

분할 및 정복 아이디어를 고려하여 DDD는 제한된 컨텍스트와 컨텍스트 매핑이라는 두 가지 중요한 디자인 메타 모델을 제공합니다.

구조적 문제: 계층화된 아키텍처 + 제한된 격리.

레이어링은 비즈니스 로직과 기술 구현 복잡성 문제를 격리할 수 있습니다. DDD가 도입한 계층형 아키텍처는 비즈니스 논리를 도메인 계층으로 캡슐화하고 비즈니스 논리를 지원하는 기술 구현을 인프라 계층에 배치합니다. 도메인 계층 위의 애플리케이션 계층은 애플리케이션 서비스를 캡슐화하고 협업을 위해 두 가지를 서로 연결합니다.

변경 문제: 변경 사항을 적극적으로 설계합니다.

변화는 통제할 수 없으며 수용할 수만 있습니다. 수요 분석 단계에서는 5W 사고를 통해 변화 패턴을 파악하고 비즈니스 변화를 통제합니다. DDD는 모델 기반 설계 메타모델을 사용하여 제한된 컨텍스트의 도메인을 모델링하고 분석, 설계 및 구현을 결합한 도메인 모델을 형성합니다.

마지막으로 DDD에서 제공하는 솔루션을 살펴보겠습니다. 패턴으로 구체화된 일련의 디자인 메타 모델을 도입하여 비즈니스 소프트웨어가 규모를 제어하고 구조를 분할하며 변화에 사전 대응할 수 있도록 합니다.

두 부분으로 나누어져 있는 이 사진을 간단히 소개하겠습니다. 첫 번째 부분은 아래 점으로 동그라미 친 부분으로, 구체적인 기술적 구현을 ​​포함하지 않습니다. 문제 공간을 처리하기 위한 일부 메타 모델 솔루션은 요구 사항 분석 단계에서 수행됩니다. 다른 부분에서는 첫 번째 부분을 기반으로 특정 시스템 아키텍처 계층화, 객체 추상화 및 집계, 서비스 분해를 수행합니다. 이 단계에서는 해당 설계를 구현합니다.

제가 이해한 바는 이 디자인 메타모델이 수요 분석, 디자인, 구현까지 완벽한 솔루션을 제공한다는 것입니다. 요구사항 분석 단계의 시스템 해체(그림의 하위 도메인 메타 모델에 해당) 그런 다음 업데이트 세분성의 제한된 컨텍스트로 분할합니다. 그리고 각 경계의 협력 관계 체계가 제공됩니다(그림의 컨텍스트 매핑 메타 모델에 해당). 설계 구현 단계에서는 시스템의 계층적 아키텍처, 도메인 서비스, 집계 등의 세분화된 설계를 통해 모델 중심 설계의 설계 요소 계획을 제공합니다. 완벽하고 이론적으로 지원되며 구현 가능한 표준 솔루션 세트를 제공합니다.

위의 DDD 분석과 문제의 복잡성에 대한 포지셔닝은 완전히 전화 로봇 시스템의 문제점입니다. 제공된 솔루션은 비즈니스가 직면한 다양한 과제도 완벽하게 해결합니다. 그 가치를 깨달은 후 팀은 후속 프로젝트에서 이를 구현하기로 빠르게 합의에 도달했습니다.

3. DDD 구현 단계

메타 모델 세부 사항과 비즈니스 경계에 대해 자세히 설명하지는 않지만 우리 팀의 실제 단계와 제품을 직접 제공합니다.

3.1 사전 연구 단계의 첫 번째 단계

이 부분에서 우리의 경험은 팀의 누군가가 선구자 역할을 하여 먼저 DDD 관련 개념에 대한 심층적인 연구에 에너지를 쏟은 다음 이를 전체 팀과 동기화하는 것입니다. . 우리 팀의 경우 연구 단계가 단편화되어 있어 얼마나 걸릴지 예측하기 어렵습니다. 팀 과학 대중화 단계는 4회에 걸쳐 8시간이 소요되었습니다. 그 후, 팀 내 학생들은 개념 지도를 바탕으로 빠르고 깊이 있게 학습할 수 있는 능력을 갖추게 됩니다. 그리고 팀원들이 서로 토론하여 이해한 내용을 확인하도록 구성합니다.

3.2 두 번째 단계는 지도 이념 및 구현 사양을 도입하는 것입니다

3.2.1 수요 분석 단계에서는 5W 모델의 이론적 지원을 도입하여 실제 요구 사항을 파악하고 변화 방향을 적극적으로 제어하며 무의미한 요구.

이 부분은 제품 요구 사항 분석을 위한 이론적 지원으로서의 5W 이론입니다. 실제 요구 사항을 파악하고 비즈니스 개발 방향을 더 잘 분석하는 데 매우 도움이 됩니다. 위 그림과 같이 소스에서 직접 유효하지 않은 요구 사항을 줄일 수도 있습니다.

3.2.2는 서비스 사양을 도입하고 문서 기반 비교 코드로 비즈니스 기능을 구현합니다. 개발 및 후속 요구 사항 정렬에 도움이 되며 단위 테스트 적용 범위에 대한 고려 사항으로도 사용할 수 있습니다.

• 3.2.2.1 서비스 사양을 먼저 작성한 후 개발해야 한다는 것이 팀원 간의 공통된 의견입니다. 서비스 사양을 작성하는 데 소요되는 시간은 실제로 요구 사항에 대한 기술적 이해를 정리하고 아이디어를 명확하게 하는 데 소요되는 시간입니다. 이 부분은 나중에 코드를 작성할 때 다시 얻을 수 있습니다.
• 3.2.2.2 서비스 사양 및 요구 사항은 단일 테스트에 해당합니다. 그건 그렇고, 이전에는 단일 테스트에 대한 표준이 없었던 문제를 해결합니다(내가 이해하는 코드 및 메서드 적용 범위는 표준이라고 할 수 없습니다).

다음은 우리 팀에서 채택한 서비스 사양 템플릿입니다.

번호: 비즈니스 서비스를 표시하는 고유 번호입니다.

이름: 동사구 형식의 비즈니스 서비스 이름입니다.

설명:

述 述 트리거 이벤트를 촉진하기 위해

원합니다:

캐릭터를 적극적으로 트리거하는 비즈니스 서비스 이벤트는 UI 컨트롤 클릭, 특정 전략 또는 관련 시스템 뉴스 등을 보낼 수 있습니다. .

기본 프로세스:

비즈니스 서비스의 주요 프로세스, 즉 성공적인 실행을 위한 비즈니스 시나리오를 표현하는 데 사용됩니다. 이는 "주요 성공 시나리오"라고도 할 수 있습니다.

대체 프로세스:

비즈니스 서비스, 즉 실행이 실패하는 비즈니스 시나리오를 표현하는 데 사용되는 확장 프로세스입니다.

허용 기준:

글머리 기호 항목에 나열된 일련의 허용 가능한 조건 또는 비즈니스 규칙입니다.

3.3 세 번째 단계는 아키텍처 솔루션을 결정하는 것입니다

DDD에서 모델 중심 설계 메타모델 솔루션을 알아보세요. 주요 목적은 책임의 경계, 즉 제한된 컨텍스트를 분할하여 전통적인 네트워크 구조 관계를 수직 분할 관계로 변경하고 상호 의존성을 줄이는 것입니다. 제한된 온라인 텍스트 분해 및 다이아몬드 드라이브 디자인의 전반적인 사용은 전반적인 이념적 지침을 형성합니다. 시스템은 계층화된 아키텍처 COLA 4.0

3.4을 채택합니다. 네 번째 단계는 팀 코딩 사양을 형성하기 위한 합의 명명 표준입니다.

합의 패키지 명명, 클래스 명명, 팀 내 입력 및 출력 매개변수에 대한 메시지 계약 및 기타 사양 . 여기서 제가 말씀드리고 싶은 것은 기준이 없다는 것입니다. 모두가 먼저 DDD의 개념을 이해한 다음 업계에서 높은 합의를 통해 명명 체계를 참조할 수 있기를 바랍니다. 동시에 팀 구성원의 프로그래밍 스타일 선호도를 고려하고 궁극적으로 자신의 팀 코딩 표준을 공식화해야 합니다.

입력 및 출력 메시지의 이름 지정을 기반으로 한 예입니다. 모든 당사자를 고려한 결과 위에 표시된 특별히 세분화된 명명 방법을 채택하지 않았습니다. 대신 팀 내에서 간단한 합의는 입력 매개변수 *요청, 출력 매개변수 *응답 명명 기준입니다.

3.5 다섯 번째 단계는 비즈니스 특성을 기반으로 제한된 컨텍스트를 식별하는 것입니다

DDD 아이디어를 기반으로 비즈니스에 대한 이벤트 스토밍을 수행하고, 통일된 언어 지침에 따라 글로벌 요구 사항 분석 및 아키텍처 매핑 설계를 수행하고, 비즈니스의 제한된 컨텍스트.

공과생들은 각자의 업무에 맞게 디자인을 하게 되는데 데모정보를 참고하시면 비교적 쉽게 찾으실 수 있으니 여기서는 자세히 다루지 않겠습니다. 제한된 컨텍스트를 식별하기 위한 안내 프로세스인 V자형 매핑 프로세스는 다음과 같습니다.

3.6 드디어 모델링 구현 단계에 들어갑니다

코딩에는 테스트 중심 개발, 즉 빨간색, 녹색, 노란색 드라이버를 사용하는 것이 좋습니다.

이 방법은 세 가지 법칙을 따릅니다. 이는 요구사항의 과소 및 과잉 설계 문제에 대한 이해를 향상시킬 수 있습니다.

Law 1	새 기능에 대한 설명으로 실패한 테스트를 한 번에 하나만 작성하세요.
제2법칙	실패한 테스트를 통과시키는 것 외에는 프로덕션 코드를 작성하지 마세요.
제3법칙	모든 테스트가 통과한 경우에만 코드 리팩토링을 수행하거나 새 기능 추가를 시작하세요.

4. 팀 개선

4.1 요구사항을 수동적으로 수용하는 것에서 적극적으로 대응하는 것까지

요구사항 분석 단계에서는 5W 원칙을 사용하세요. 요구사항의 합리성을 분석하고, 프로젝트 방향 변화를 선제적으로 제어할 수 있습니다. '3번 과제'를 해결하여 수요 가치를 파악하고, '4번 과제'를 개선하여 사업 발전 변화의 방향을 통제합니다.

4.2 커뮤니케이션 비용 절감

통일된 언어와 이념적 커뮤니케이션을 활용하여 "Challenge Five"의 모든 측면에서 협업 비용을 절감합니다.

4.3 아키텍처 설계 개선

하위 도메인 모델과 메타 모델의 경계 컨텍스트를 설계하여 코드 크기를 합리적으로 해체합니다. DDD의 계층적 사고를 통해 비즈니스 로직과 기술 차원의 복잡성이 분리되고 코드 구조가 명확해집니다. 동시에 이 프로젝트는 다이아몬드 모양의 대칭 구조를 채택하고 남북 게이트웨이를 통해 외부와 상호 작용하여 모듈 네트워크의 발생을 방지합니다. "챌린지 2"의 문제를 해결하고 "챌린지 1"의 복잡성을 줄였습니다.

4.4 기술적 구현 개선

비즈니스 기능을 개발할 때 팀은 요구 사항의 합리적인 한계를 고려할 것입니다. 구현 과정에서 이를 도메인 계층에 배치할지, 비즈니스 서비스 계층에 배치할지, 기능 구현을 위해 빈혈 모델을 사용할지 혼잡 모델을 사용할지 여부를 고려하게 됩니다.

4.5 문서 사양 개선

문서 사양 측면에서 서비스 사양 메커니즘이 도입됩니다. 요구 사항을 분류하는 도구와 단일 테스트의 기초로 사용할 수 있습니다. 동시에 나중에 사용할 수 있도록 서비스 설명 문서도 제공됩니다.

4.6 코드 구현 개선

코드 구현 측면에서 아키텍처부터 코딩 구현 및 명명까지 일련의 표시된 사양이 구성되었습니다.

일반적으로 이 모드에서는 팀의 사고 방식이 바뀌었습니다. 다양한 메타 모델을 적용함으로써 수요 분석부터 시스템 아키텍처 및 코드 구현에 이르기까지 다양한 측면에서 발생하는 과제를 해결할 수 있습니다.

5. 이론에서 실제까지의 충돌

5.1 빈혈 모델 PK 혼잡 모델

빈혈 모델: 일반인의 용어로 도메인 개체에 속성에 대한 getter/setter 메소드만 있는 순수 데이터 클래스이며 비즈니스가 모두 있습니다. 로직과 애플리케이션 로직이 서비스 계층에 배치되는데, 마틴 파울러(Martin Fowler)는 이 모델의 도메인 개체를 "빈혈 도메인 개체"라고 부릅니다.

혼잡 모델: 반대로 혼잡 모델에는 객체의 속성뿐만 아니라 비즈니스 로직을 포함한 객체의 동작도 포함됩니다.

객체 지향 관점에서 객체에는 속성과 동작이 포함되어 있으므로 혼잡 모델을 사용해야 하며, DDD에서도 혼잡 모델 사용을 원칙으로 권장합니다. 그러나 구체적인 개발 상황을 보면 빈혈 모델이 많은 문제를 안고 있음에도 불구하고 업계에서 수년간 사용되어 왔고 널리 사용되고 있으며 여전히 그 가치가 있습니다. 또한 대부분의 JAVA 애플리케이션은 Mybatis 기술 스택을 사용하며 많은 개체는 플러그인에 의해 자동으로 생성되는 빈약한 개체입니다. 따라서 문제는 충혈 모델을 채택한다는 것은 몇 가지 편리한 도구를 포기한다는 것을 의미한다는 것입니다. 이 문제에 대해서는 팀 내에서 큰 차이가 있습니다. 결국 우리의 접근 방식은 이 부분에 대해 엄격한 기준은 없지만 혼잡 모드를 사용하는 것이 좋습니다.

5.2 데이터 변환 제약사항을 엄격히 준수

PK는 외부 데이터를 직접 능률적이고 효율적으로 사용

DDD ​​사상으로, 도메인 서비스의 신뢰성을 보장하기 위함입니다. 도메인 서비스가 의존하는 데이터는 도메인 내 엔터티 및 집계 데이터여야 하며, 외부 메시지 계약 데이터를 직접 사용할 수는 없습니다. 다이아몬드 대칭 아키텍처에 따라 데이터를 얻기 위해 남북 게이트웨이를 변환하면 추가 작업 부하가 발생합니다. 일부 팀원들은 상대적으로 안정적인 특정 구조는 이 원칙을 준수할 필요가 없다고 제안했습니다. 그 이유는 개발 속도를 높일 수 있으며, 데이터의 90%는 데이터베이스와 같은 상대적으로 안정적인 구조를 가진 리소스일 수 있다고 생각하기 때문입니다. 그러나 결국 팀은 여전히 ​​이러한 지도 이념을 준수해야 했습니다.

5.3 캐시 처리를 통해 공유 PK 경계 격리가 가능합니다.

동일 시스템의 서로 다른 경계에서 캐시 처리: 공유 PK 경계 격리가 가능합니다.

당시 시나리오로 판단하면 공유를 허용하면 단기적으로 작업량을 줄이고 리소스를 절약할 수 있습니다. 하지만 우리가 경계를 긋는 이유는 관계를 깨뜨리고 너무 커지는 것을 막기 위해서이다. 여기에 제시된 제안은 데이터를 공유하는 서비스를 하나의 경계로 병합하는 것이 합리적인지 먼저 고려하는 것입니다. 병합이 불가능하면 데이터를 격리해야 합니다.

5.4 서비스 사양은 요구 사항의 프런트엔드 PK 백엔드를 비교합니다

안내하는 이론적 아이디어가 매우 아름답고 수요 분석 중에 기술적 구현 사고를 보호해야 합니다. 그러나 결국 기술 스택에서 구현되어야 합니다. 기술 구현에 관해서는 기술 구현에 의해 방해를 받게 됩니다. 당시 두드러진 문제는 기능 구현을 프런트엔드에 배치할 수도 있고 백엔드 서비스로 구현할 수도 있다는 점이었습니다.

예 1: 요구 사항에는 "id+name" 조합 표시가 필요하지만 백엔드 인터페이스에서 반환된 id와 이름의 두 필드는 실제 프런트엔드 기술 스택과 프런트엔드에 대한 서비스 사양에 의해 결합됩니다. 엔드와 백엔드가 일치하지 않습니다.

예 2: 요구사항에서는 매개변수가 비어 있지 않은지 확인해야 합니다. 일부 내부 시스템에서는 우리 팀의 기술팀이 프런트엔드 및 백엔드 풀스택 엔지니어로 구성되어 필요에 따라 작업을 나누고 모듈을 개발합니다. 종종 그들은 양쪽 끝을 검증할 만큼 엄격하지 않습니다. 이는 또한 서비스 사양을 지향하는 충돌로 이어집니다.

최종 선택: 팀은 백엔드 서비스 계층을 채택합니다. 하지만 동시에 검증 및 기타 기능을 인터페이스 수준으로 이동하는 등 몇 가지 개선 사항을 적용할 예정입니다.

5.5 서비스 사양이 정확하게 작성되었는지, 제품 PK 기술이 있는지는 누가 확인하는가

초기 단계의 이상적인 상태는 수요 측 제품에 의해 검증되는 것이며, 필요한 사람이 이를 확인한다는 원칙을 바탕으로 합니다. 다만, 4.4의 차이점으로 인해 실제 구현은 기술담당자가 검토하게 됩니다.

6. DDD 애플리케이션의 향후 개선 사항 및 요약

DDD ​​​​애플리케이션 팀에서는 현재 아키텍처 및 사양 측면에서 이를 구현했습니다. 그러나 집계 클래스, 엔터티 및 값 개체의 설계와 같은 일부 세부 사항은 특별히 상세하지 않습니다. 우리는 앞으로 이러한 세밀한 개선을 더욱 발전시켜 나갈 것입니다. 동시에 사용 중인 일부 오래된 프로젝트는 DDD 아이디어에 따라 변형 및 재구성됩니다.

DDD를 적용하면 개발 효율성이 떨어진다고 생각하는 사람들도 있습니다. 이는 많은 팀의 관심사이기도 합니다. 이것이 우리가 이 문제를 보는 방식입니다. DDD를 적용하는 시나리오는 복잡한 비즈니스 문제를 해결하는 것이며, 이로 인해 실제로 코드의 양이 늘어납니다. 하지만 그렇다고 해서 개발 효율성이 떨어지는 것은 아닙니다. 명확한 아키텍처 구조, 통합된 도메인 서비스 및 표준화된 표준은 향후 수요 업그레이드, 코드 유지 관리 및 복잡성 제어에 대한 투자보다 훨씬 더 큰 이점을 가져올 것입니다. 또한 소프트웨어 업계에서 제공한 데이터에 따르면 수요 분석 및 설계에 80%의 시간이 소요되고 개발 시간은 20%에 불과합니다. 따라서 손실의 이 부분은 초점이 아닙니다.

마지막으로 DDD 사용 경험을 설명해 주세요. DDD 메타 모델에는 다양한 유형이 있으며, 비즈니스가 직면한 문제점을 기반으로 모든 사람이 이를 학습하고 의도적으로 채택할 수 있습니다. 실제 비즈니스 환경에서 우리의 도메인 모델은 다소 "특수성"을 가지고 있습니다. DDD 사양을 100% 준수하면 비용이 상대적으로 높을 수 있으므로 가장 중요한 것은 DDD 아이디어를 이해하고 최종적으로 만드는 것입니다. 귀하의 비즈니스에 적합한 솔루션을 선택하세요.

저자 소개

Li Xiaohua

• 딜러 사업부-딜러 기술부.
• 2016년 오토홈에 입사해 현재 딜러 데이터 아키텍처팀에서 폰로봇 프로젝트를 담당하고 있습니다.

위 내용은 폰로봇팀의 DDD 실습의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!