DDD에 대한 나의 주요 이해에 대해 이야기해 봅시다.

저자: Min Dawei Ali 비즈니스 플랫폼 솔루션 팀

DDD를 배우는 과정에서 배울 수 없다고 느낄 때 우리는 다음과 같은 질문을 할 수 있습니다. 여전히 배울 필요가 있습니까? 이것은 참으로 생각을 자극하는 것입니다. 업무 경험을 바탕으로 이 기사에서는 DDD에 대한 이해에 대해 이야기하려고 합니다.

1. 서문

"포레스트 검프"에서 포레스트 검프는 쉬지 않고 달리기 시작했고 얼마 후 많은 추종자들이 함께 달렸습니다. 그들은 왜 달렸을까요?

• 포레스트 검프: 모르겠어, 그냥 뛰고 싶어.

• 추종자: 그렇게 하는 것이 의미가 있고, 포레스트 검프가 여전히 그 길을 이끌고 있습니다.

마찬가지로 처음에는 DDD가 뭔지도 몰랐는데 모두가 DDD를 언급하고 DDD를 배우는 것을 보고 저도 무심코 주자처럼 운동에 동참하게 되었습니다. 그것에는 바라는 것이 있어야 합니다.

그러나 어느 날 A-Gump는 달리기를 멈추고 달리고 싶지 않았고 추종자들은 문제에 직면했습니다. 우리는 여전히 달리고 싶습니까? DDD를 배우는 과정에서 배울 수 없다고 느낄 때 우리는 또한 다음과 같은 질문을 할 수 있습니다. 우리는 여전히 배울 필요가 있습니까? 이것은 참으로 생각을 자극하는 것입니다.

업무 경험을 바탕으로 이 기사는 DDD 학습의 의미를 더 잘 탐구하기 위해 DDD에 대한 어느 정도의 이해에 대해 이야기하려고 합니다.

2. DDD의 가치에 집중하라

비즈니스를 하든, 플랫폼을 하든, 미들오피스를 하든, 얽히고설킨 복잡한 비즈니스 로직과 모호하게 결합된 비즈니스 코드에 지칠 때가 많습니다. 모두가 DDD를 추구하는 것은 사업 발전에 대한 손쉬운 지원에 대한 요구이기도 하다고 생각하고 현상 유지를 개선할 수 있는 적절한 이론이 있는지 탐색하고 있습니다. 결국, 더 나은 삶은 공유됩니다.

2.1 상태: 계층화된 지원 메커니즘

우리는 다양한 프레임 워크를 선택하고 다양한 조직 설계를 수행하며 그 핵심은 생산 효율성을 향상시키는 것입니다. 그러나 비즈니스 로직이 사례별로 구현되고 재사용이 부족하면 R&D 비용이 매우 높고 투자 주기가 매우 길어집니다.

재사용을 늘리고 서비스 시작 시간을 단축하려면 많은 범용 기능과 제품이 필요합니다. 배송 프로세스에는 두 가지 주요 계층이 있습니다.

• 기본 기능: 상대적으로 원자적인 기능은 기본(도메인) 기능으로, 비즈니스 사용자 지정을 더 잘 지원할 수 있습니다. 기본에 대한 비교로 인해 표현되는 제품 기능의 범위도 매우 넓습니다. 그러나 완전한 제품은 많은 기본 기능을 직렬로 요구하며 직렬 연결 비용도 매우 높습니다.

• 플랫폼 제품: 기본 기능의 다재다능함은 현장에 대한 이해 부족과 생산 효율성을 더욱 향상시키는 "유전자"가 부족함을 의미합니다. 따라서 배송 시 추상화는 일부 고주파 시나리오를 기반으로 플랫폼의 제품 기능을 형성하고 "즉시 사용 가능"을 달성하기 위해 노력합니다. 비즈니스가 "플랫폼 제품" 레이어를 기반으로 맞춤화되면 이해 비용이 크게 절감됩니다.

계층 지원 프레임

2.2 부패: 비즈니스 로직 침투

이 수준은 매우 좋아 보입니다. 초기 단계에서는 역사적 부담이 없기 때문에 실제로 특정 생산 효율성을 향상시킬 수 있으며 이는 능력 자체의 이점입니다. 그러나 시간이 지남에 따라 비즈니스 접근이 증가함에 따라 비즈니스가 서로 영향을 미치기 시작하고 연구 개발에 대한 저항도 증가하고 있습니다.

R&D 효율성이 떨어지는 중요한 이유는 여전히 "비즈니스가 얼마나 빨리, 얼마나 빨리 운영될 수 있는가"의 논리를 따라 관련 작업을 수행하고, 물을 만나면 다리를 만들고, 산을 만나면 구멍을 뚫고, 정보를 수행하기 위해 목적지로 직접 이동 통신, 데이터베이스 필드의 작업.

이러한 프로세스는 "깨끗한 커널을 보장하면서 비즈니스 시나리오를 통해 플랫폼 기능을 강화하기를 희망한다"는 우리의 원래 의도를 위반합니다. 기능은 상대적으로 많은 수의 사용 사례와 상대적으로 완전한 사고를 기반으로 추상화되어야 합니다.수평에 대한 통합 보기이며 더 깊은 이해가 있습니다.그러나 수직 전달은 우리가 문제를 보다 수직적으로 처리할 수 있도록 합니다. 종종 "스누핑" 배달 시간과 비즈니스 노드의 제약 하에서 더 포괄적이고 심오하게 생각하기 어렵고 더 일반적인 디자인을 만들기가 어렵습니다.

2.3 저항: 플랫폼 프레임워크 가드

그렇다면 왜 DDD에 집중해야 할까요? DDD가 소프트웨어 복잡성의 핵심인 "문제 영역"에 직접 닿는다면 여전히 상대적으로 추상적일 수 있습니다. 구체적으로 이것은 우리가 추구하는 가치 [장기적 생산성 향상] 과 맞닿아 있기 때문입니다 .

• 분야 세분화 및 전문 인력 및 사물 양성: DDD의 핵심은 각 분야를 잘 이해하고 포장하는 것이기 때문에 비즈니스 요구 사항을 분해하고 합리적인 위치에 배치하고 이러한 분해 및 강수를 통해 도메인 입력이 장기적으로 달성할 수 있도록 보장합니다. 용어 지속 가능한 개발 및 형태 경쟁력.

• 변경 가능한 항목에 의존하지 않는 메커니즘 보장: DDD는 실제로 이러한 구현을 보다 결정적으로 만들 수 있는 많은 공통 기술과 경험을 요약합니다. 도메인 엔터티를 제어하는 ​​집계 루트의 기능, 제한된 컨텍스트의 상호 작용 전략, 도메인 코어의 추상 상태 등 여부에 관계없이 일단 존중하고 확인하기로 선택하면 코드 구조, 조직에 빠질 수 있습니다. 관계 및 팀 문서 합의가 형성되고 인력 및 기타 요인의 변경으로 인해 격렬하게 변동하지 않습니다.

DDD에 대한 초점은 "장인 정신"에 대한 우리의 초점과 비교할 수 있습니다. DDD에 대한 초점은 비즈니스 이해에 대한 우리의 초점이기도 합니다. 비즈니스와 친해지려면 비즈니스를 이해하는 것뿐만 아니라 대부분의 비즈니스를 이해하는 것이 필요합니다. 이런 종류의 추구는 우리가 수준을 올려보고 가장 본질적인 질문으로 돌아갈 수 있게 해줍니다. 우리가 해결하고 싶은 문제는 무엇입니까? 어떻게 더 잘 해결할 수 있습니까?

3. DDD 학습의 어려움

당신이 그렇게 혼란스러워하는지 모르겠습니다. DDD의 학습 과정은 "건초더미에서 바늘 찾기" 과정인 것 같습니다. 무언가를 얻고 사용할 수 있어도 여전히 "가짜"라는 느낌이 들며 이는 그다지 자연스럽지 않습니다. DDD를 배우는 것이 왜 그렇게 어려운가요?

3.1 감정: 문이 없다

논어의 다음 장면은 우리의 혼란과 매우 유사합니다.

Wu Shuyu 삼촌은 법정에서 의사에게 말했습니다. 집의 아름다움을 볼 수 있고 주인의 성벽은 100,000에 이르고 문은 들어갈 수 없으며 종묘의 아름다움과 수백 명의 관리의 재물이 보이지 않습니다. 문을 얻는 사람 소수일 수 있으며 마스터의 클라우드는 적합하지 않습니다!"

공자가 이룬 경지를 느끼고 싶은 것처럼 자신의 지식도 어느 정도 축적되어 있어야 합니다. DDD의 힘을 느끼고 싶다면 공명과 인식을 형성하기 위해 어느 정도 성장해야 합니다.

작업에서 DDD의 모범 사례는 거의 보이지 않는 것이 사실입니다. 복잡한 비즈니스 앞에서 어떤 소프트웨어 구조가 이상적인 디자인인지 말할 용기가 있는 사람은 아무도 없습니다.

• 이것은 결정론적 문제 분해가 아니기 때문에 귀하의 디자인은 현미경으로 연구될 것이며 다양한 반례를 항상 찾을 수 있습니다.

• 또한 우리는 모범 사례가 충분히 "부드럽고" 확장을 위한 디자인을 남겨두고 정적인 결과가 아니라 비즈니스 개발을 반복할 수 있어야 한다는 것을 알고 있습니다.

따라서 배움의 문을 여는 것은 몇 가지 사례로 하루아침에 이루어질 수 없고, 우리 자신의 일과 결합하여 천천히 축적하고 경험해야 합니다.

3.2 난이도: 패턴 발산

DDD가 정확히 무엇인지 헷갈립니다.

• 연습의 예는 설득력이 없습니다. "DDD 연습"을 보면 다음과 같이 질문할 수 있습니다. 이것도 DDD입니까? 일반적인 서버 측 프레임워크 및 솔루션이 아니며 다른 시나리오나 부서 시스템을 다룰 수도 없습니다.

• 추상 이론은 공허함을 느낍니다. "추상적인 DDD 정의 및 전략"을 볼 때 다음과 같은 질문을 할 수 있습니다. 이것도 DDD로 간주됩니까? 일부 소프트웨어 디자인 합의에 불과하고 일부 명사 정의가 부과되고 일부 전략이 우리가 가진 시스템과 일치하지 않는 것이 아닙니까?

추상화나 특정 구현을 살펴봐도 설득력 있는 이론과 실제(결정론적 구현 가능)를 찾기가 어렵습니다. 23개의 디자인 패턴과 다르기 때문에 대부분의 패턴을 N개의 템플릿으로 커버할 수 있습니다.

특정 패턴을 생성할 수 없는 이유는 무엇입니까? 다음 그림을 자세히 살펴볼 수 있습니다.

• 추상 이론: 추상 인터페이스와 마찬가지로 "DDD 이해"의 상위 학습은 주로 이론적 정의입니다. 예를 들어 집계 루트, 값 개체, 리소스 라이브러리, 핵심 도메인, 지원 도메인 및 기타 정의는 이해하고 파악하기 쉽습니다.

• 일반 사례: 상대적으로 구체적인 추상 클래스와 마찬가지로 중간 수준의 "DDD 이해"는 컨텍스트 매핑 전략, 아키텍처 선택 등과 같은 몇 가지 일반적인 원칙 및 기술입니다. 이러한 요소는 확실하지만, 스스로 절충과 선택을 해야 하고, 시대에 발맞추어야 하며, 점진적인 부분은 스스로 학습하고 보완해야 합니다.

• 특정 사례: 특정 클래스 인스턴스와 마찬가지로 "DDD 이해"의 하위 수준은 다양한 요소를 설계, 선택 및 보완하기 위해 각각의 비즈니스 시나리오와 결합된 일련의 특정 사례입니다. 관련된 옵션이 많기 때문에 최종 선택 결과가 종종 다른데, 이는 사람들이 "수천 명의 사람들이 수천 개의 얼굴을 가지고 있다"고 느끼게 합니다.

둘의 차이점은 다음과 같습니다.

• "코드 추상화 수준"의 계층적 관계는 상대적으로 명확하고 제한적입니다.

• 여러 전략과 몇 가지 주요 제안의 절충점인 "도메인 중심 이해 수준"에는 명확한 제약이 없습니다.

따라서 문제의 높은 추상화 수준과 다양한 전략의 높은 불확실성으로 인해 DDD에서 "23가지 디자인 패턴"만큼 정제된 패턴을 생성하기 어렵습니다. 있어야 한다면 상대적으로 발산하는 일련의 패턴이기도 하다.

DDD 이해 수준의 유추

따라서 우리는 DDD가 모든 측면을 포괄하는 소프트웨어의 "소프트"를 지향한다는 점을 점차 이해합니다. DDD에 대한 심층적인 이해는 이러한 심층적이고 간단한 제안을 이해하기 전에 "수천 번의 시도"가 필요하며 "마스터가 문을 이끌고 연습은 개인에 달려 있습니다"라는 모토를 이해할 수 있습니다. "군중은 그를 수천 번 찾지만 그 사람은 세상에 있다"고 느낄 수 있습니다. 희미한 곳에서 멋진 순간.

넷째, 디자인 원칙에 입각한 DDD를 보라.

DDD의 실행 자체는 수천 명일 수 있지만 일부 핵심 주제에 대한 생각은 집중되어야 합니다.이러한 빈도가 높은 주제에 대한 이해는 우리가 더 나은 설계를 가능하게 할 수 있으며 토론의 비용 효율성도 높습니다. 다음으로 "6가지 주요 설계 원칙"(견고한 원칙)을 소개로 삼아 DDD에 대한 몇 가지 주요 이해 사항을 살펴보겠습니다.

4.1 단일 책임 원칙: 영역 분할

Single Responsibility는 다음과 같이 말합니다. 클래스는 변경해야 할 이유가 하나여야 합니다. 단일 책임은 더 나은 응집력을 허용하고 결합을 줄이며 진화를 촉진합니다.

DDD의 도메인 분할은 유추하여 생각할 수 있습니다. 도메인 분할의 경우 도메인 엔터티, 기능 모듈 또는 서비스로 분할되는지 여부에 관계없이 실제로 도메인이 가능한 한 직교하고 독립적으로 진화하고 개발할 수 있기를 원합니다.

단일 책임 원칙: 단일 책임 원칙

필드를 나누는 방법이 더 적절합니까? 비즈니스 플랫폼에 처음 입문했을 때 도메인 세분화는 "하나 이상의 엔터티 개체"의 경계를 기반으로 한다는 것을 알게 되었습니다. 도메인의 핵심 책임은 도메인 엔터티를 관리하는 것이기 때문에 이것은 실제로 더 합리적입니다. 그러나 이것은 결과입니까, 아니면 원인입니까? 분할할 때 도메인에 대한 판단이 있어서 일부 개체가 함께 그룹화되는 것이 더 적합합니까, 아니면 일부 개체는 경계가 명확하여 도메인을 형성할 수 있습니까? 아래 그림과 같습니다.

• 전체를 부분으로 사용할 수 있습니다.

• 수직 양수 및 음수에 따라 2개 부분으로 나눌 수 있습니다: 위 1개(빨간색), 아래 2개(노란색, 녹색).

• 가로축의 양수와 음수에 따라 왼쪽 1개(노란색)와 오른쪽 2개(빨간색 및 녹색)의 두 부분으로 나눌 수 있습니다.

• 3부분(빨간색, 노란색, 녹색)으로 절단할 수 있습니다.

클러스터링 예시

이것은 참으로 생각할 거리입니다. 세분화가 상대적으로 쉬운 경우는 이미 업계 표준이 있기 때문인 경우가 많습니다(예: 전자 상거래 시스템에 주문, 결제, 물류 및 재고와 같은 필드가 있는 것이 더 합리적임). 업계 표준은 어디에서 오는가? 진화에서 온다:

• 처음에는 큰 거래일 수 있습니다. 예를 들어 지불 초기에는 구매자와 판매자 간의 계약일 뿐이며 모델링이 필요하지 않습니다.

• 나중에 결제가 발전하면서 영역이 독립되었습니다. 과거에는 전담 유지 보수가 필요하지 않았으며 관련 연구 개발을 수행하기 위해 점차 팀을 끌어낼 것입니다.

따라서 도메인의 진화 및 분할은 "휴리스틱 알고리즘"(합리적 최적화 문제의 각 인스턴스에 대해 허용 가능한 비용으로 해결될 수 있는 실행 가능한 솔루션을 제공하는 직감 또는 경험에 기반한 알고리즘)과 매우 유사합니다.

• 초기화: 예비 경험 분할에 따르면 업계 표준이 될 수도 있습니다(업계 표준이 없으면 경험에만 의존할 수 있음).

• 비용 평가: 비용 이해, 개발 효율성, 시스템 안정성, 운영 및 유지 보수 비용과 같은 요소에 중점을 둔 생산 및 배송 프로세스의 인적 비용 측정.

• 더 나은 솔루션: 비즈니스 개발 과정에서 비용 평가를 계산하고 평가에 영향을 미치는 "좋은 요소"와 "나쁜 요소"를 분석하고 추가 조정을 합니다.

종종 결국에는 다음을 찾을 수 있습니다.

• 조정 내용 : 사실상 제작 관계를 맞추기 위함이다.

• 조정의 원칙: 책임의 결속을 추구하고 분업을 개선합니다.

• 지속적으로 조정해야 하는 이유: 비즈니스가 발전함에 따라 응집력 표준은 시대와 보조를 맞춰야 합니다.

또한 연합의 관점에서 보면 조직구조를 보면 현장의 경계가 보이는 경우가 많은데 그 핵심적인 이유는 조직구조도 생산관계에 적응해야 하기 때문이다.

4.2 개방-폐쇄 원칙: 개체 행동

열기 및 닫기의 원칙은 소프트웨어의 개체(클래스, 모듈, 함수 등)가 확장에는 열려 있고 수정에는 닫혀 있어야 함을 의미합니다. 즉, 확장 블록을 설계해야 하며 확장 부분이 안정성 논리에 영향을 미치지 않아야 합니다.

DDD에서 엔터티의 동작은 외부 세계에 대해 닫혀 있음을 확인하면서 확장할 수 있는 기능도 고려해야 합니다.

개방 폐쇄 원칙: 개방 및 폐쇄 원칙

DDD를 처음 배우기 시작했을 때 제어 및 수렴을 위해 일부 논리를 엔터티에 강제로 적용할 수 있습니다. 그러나 나중에 비즈니스가 변경되면 엔터티에서 동작 논리를 가정하기가 어려워집니다.

• 더 큰 영향: 핵심 클래스를 자주 수정하는 용기를 갖기가 어렵습니다.

• 과도한 중앙 집중화: 메서드와 논리가 증가함에 따라 엔터티는 점점 더 비대해집니다.

• 많은 시나리오가 있습니다. 많은 논리가 교차 및 중첩으로 가득 찬 if 또는 else와 같이 직교하지 않습니다.

POJO의 get 및 set을 포기하고 엔티티의 풍부한 동작으로 이동하면 코드 작성이 더 어려워집니까? 사실, 우리의 문제는 엔터티 동작의 종료에 너무 많은 주의를 기울이고 확장 디자인을 무시하는 데서 발생합니다.

• 원래 get set 작성 방법의 본질은 많은 확장이 비즈니스 스크립트에 배치된다는 것입니다.비즈니스 스크립트는 허점으로 가득 차 있지만 응용 프로그램 계층에 있으며 핵심 논리에서 떨어져 있습니다. 기본 모델 및 공통 구성 요소와 같은 기본 논리는 비교적 깨끗합니다.

• DDD를 적용할 때 일부 동작을 도메인 계층으로 싱킹한 후 확장도 고려해야 합니다. 폐쇄에만 주목하고 확장에는 관심을 기울이지 않는다면 그것은 참으로 "감옥으로 땅을 그리는 것"과 "씨앗을 줍고 수박을 잃는 것"입니다.

그러나 이 딜레마를 극복하고 개체 동작의 확장을 설계할 수 있으려면 실제로 이러한 인식이 있어야 합니다. 개체 동작의 표현인 수준을 올려다봐야 합니다. 오직 하나의 클래스에 의해 완료됨 전략 패턴 및 기타 방법을 통해 수행될 수 있음 라우팅은 외부 캡슐화 및 제어가 있는 한 모듈의 일부 클래스에 의해 수행됨

또한 한 클래스의 한계를 뛰어넘어 더 많은 클래스의 협업 설계로 나아가는 것이 우리의 발전된 방향이기도 합니다.

4.3 Liskov 대체 원칙: 리소스 라이브러리

Liskov 대체 원칙은 기본 클래스가 나타날 수 있는 모든 위치에 하위 클래스가 나타나야 한다는 것입니다. 중요한 것은 합리적인 추상화와 재사용입니다. 생각을 불러일으키는 예: 정사각형은 특수 직사각형입니다. 정사각형이 직사각형의 하위 클래스인 경우 길이를 설정할 때 충돌이 발생합니다. 직사각형의 길이와 너비는 독립적으로 설정할 수 있으며 길이와 사각형의 너비가 제한되어 있습니다.네, 상속 관계를 사용하는 것은 어색합니다.

DDD에서는 대체 가능성과 관련하여 리소스 라이브러리에 대해 이야기하고 싶습니다.

Liskov 대체 원리: Liskov 대체 원리

리포지토리에 대한 대체 요구 사항

원래의 계층화된 아키텍처에서는 데이터베이스와 같은 저장소 기능을 기반 인프라로 안정적인 기반 서비스로 간주했습니다. 그러나 실제 배송 프로세스에서는 다음과 같은 다양한 시나리오가 자주 발생합니다.

• 로컬 배포: 오프라인 소매 거래는 서비스 안정성을 위해 데이터를 로컬에 저장할 수 있는 기능이 있어야 합니다.

• 클라우드 상의 상품: 외부 기업에 판매되는 거래 상품은 비용 요구 사항이 다르며 클라우드에서 다양한 스토리지 서비스를 구매할 것으로 예상됩니다.

이러한 시나리오로 인해 모든 사람들은 점차 더 넓은 시장에 직면할 때 인프라도 불확실성으로 가득 차 있으며 교체해야 한다고 믿게 되었습니다.

스토리지 구현 간의 재사용 전략

실제 구현 과정에서 모든 필드가 독립적으로 배치되는 것은 아니며 일부 필드는 조직 및 성능 요인으로 인해 함께 배치됩니다. 종종 이러한 영역의 코드는 프로젝트 모듈에도 있습니다. 수평적 효율성을 고려하여 통합 스토리지 프레임워크를 설계합니다.

시설마다 저장 능력은 다르지만 전체 저장 프로세스(프로토콜 변환, 저장 명령문 생성, 실행 및 트랜잭션, 반환 결과)는 유사하므로 서로 다른 저장 능력의 프로세스 재사용 방법에서 절충이 필요합니다. 데이터베이스, Tair 등 별도의 추상화입니까 아니면 통합 추상화입니까):

"큰 통합"이 주요 초점이라면 관계형 스토리지 및 KV 스토리지와 같은 다른 스토리지를 추상화할 때 "사각형과 사각형의 문제"처럼 주저할 것입니다.

• 이점: 오랫동안 유지하고 내부의 특수성을 이해하면 실제로 일부 주요 코드를 생략하고 개발 효율성을 향상시킬 수 있습니다.

• 비용: 그러나 대부분의 사람들이 확장을 원할 때 많은 혼란을 느낄 것입니다.불필요한 적응이 많아 혼란이 가득합니다.

초점이 조합에 있는 경우 여러 템플릿 세트를 사용하여 더 나은 독립적인 선택을 할 수 있습니다. 이러한 종류의 분할 정복은 모든 사람의 이해 비용을 줄이고 독립적으로 발전할 수도 있으므로 스토리지의 기능과 특성에 더 적합합니다. 그러나 여러 세트의 이해가 축적되어야 하며 인적 지원이 부족한 경우가 많습니다.

"다른 스토리지 기능을 기반으로 다른 템플릿 프레임워크를 디자인"하는 것이 첫 번째 선택이 되어야 한다고 생각합니다. 통일된 추상화는 처음에는 인건비가 낮을 수 있지만 추상화 수준이 높기 때문에 이해와 유지 관리에서 "인적 비용의 블랙홀"이 될 것입니다. 장기적으로 볼 때 손실 가치가 없을 것입니다. 반대로 다른 템플릿을 재사용하여 결국 더 나은 전반적인 이점을 얻을 수 있습니다.

4.4 데메테르의 법칙: 도메인 협업

최소 지식 원칙이라고도 하는 데메테르의 법칙은 소프트웨어 엔티티가 다른 엔티티와 가능한 한 적게 상호 작용해야 함을 의미합니다. 일부 "키 클래스"와 통신해야 합니다.

DDD에서 도메인 간의 공동 작업에는 관련 계획 및 설계도 필요합니다. 도메인 간의 상호 호출이 관리되지 않으면 링크 관계가 이해할 수 없는 지점까지 확장됩니다.

데메테르의 법칙: 데메테르의 법칙

디자인 패턴에서는 중간 패턴이든 외관 패턴이든 중앙 집중식 관리를 통해 복잡한 다대다 관계를 다대일과 같이 이해하기 쉬운 구조로 단순화할 수 있기를 바랍니다. 그리고 일대다. 마찬가지로 도메인 협업 및 외부 전달 과정에서 조정 계층을 추가하여 다양한 도메인의 상호 작용을 연결할 수 있습니다. 이를 통해 각 도메인의 협업 비용을 줄일 수 있을 뿐만 아니라 외부 이해 비용을 줄이고 더 나은 R&D 경험을 얻을 수 있습니다.

조정 레이어는 어떻게 생성해야 합니까? 수업에 참석하는 것과 같습니다. 교사가 가르칠 수 있지만 교사가 없을 때 수업에 참석할 학생을 지정할 수 있습니다. 학생들은 할 수 있지만 가르치는 기술에 능숙하지 않고 스스로 학습에 대한 책임이 있으며 역할도 매우 부끄럽습니다. 조정 계층과 도메인 간의 역할 관계는 아래에서 설명합니다.

도메인이 조정 계층이 될 수 있습니까?

논의할 가치가 있는 것은 트랜잭션에서 "거래 도메인" 및 "주문 도메인"의 개념입니다.

• "트랜잭션 도메인"은 전체 트랜잭션 프로세스를 담당하는 것으로 보이며 다양한 도메인을 조정할 수 있습니다. 논리적으로 코디네이터가 더 적합하지만 주로 주문 관리 및 기타 조정 기능이 부여됩니다. 도메인 엔터티가 없습니다.

• "오더 도메인"은 오더 자체의 서비스만 담당하는 것 같고, 다른 도메인에 대해서는 크게 신경쓰지 않지만, 오더 컨트랙트는 모든 컨트랙트 정보(직간접적으로 보유하고 있는지 여부)를 가지고 있기 때문에, "주문 영역" 자체에는 조정 가능성이 있지만 책임은 충분히 단일하지 않은 것 같습니다.

엔터티가 없으며 "거래 도메인"이 있는 이유는 다음과 같습니다. 거래 프로세스를 강력하게 제어하는 ​​경우 거래의 API 서비스는 도메인 서비스로 간주됩니다(예: 주문하기). ), "트랜잭션 도메인"은 논리적으로 경계가 있고 설정할 수 있습니다. 그러나 본질은 여전히 ​​주문을 관리하고 주문 도메인에 의존하여 도메인이 되고 동시에 조정 능력을 축적하고자 합니다.

조정 레이어가 도메인이 될 수 있습니까?

따라서 주문 모델의 관리가 거래 관리에 주어지지 않는다면 이것은 내가 항상 생각했던 질문입니다. 자체 데이터베이스 엔터티가 없는 경우 메모리 모델만 있고 순전히 다운스트림 비즈니스의 이해에 의존합니다. 활동 및 데이터 흐름, 도메인이 될 수 있습니까? ?

대답은 '아니오'일 가능성이 높습니다.

• 논리적으로 개인은 순전히 영역으로 이해함으로써 인식하며, 결국 지식 자체도 자산입니다.

• 하지만 사실 통신사 없이는 상태 기록, 데이터 서비스 등 많은 일을 할 수 없고 도움만 줄 뿐 핵심 경쟁력 없이는 생존하기 어렵습니다.

코디네이터의 역할은 상대적으로 인정받는 "도메인"이 되기 위해 자체적으로 데이터 모델을 보유하거나 기본 도메인의 일부 데이터 모델을 사용하고 관리 권한을 향유해야 합니다.

조정 레이어의 이름

도메인이 코디네이터의 역할을 맡기를 원하든 코디네이터가 도메인으로 발전하길 원하든 단일 책임의 논리에 부합하지 않지만 이러한 "알바"가 자주 발생하며 핵심은 개발자의 중첩입니다. 역할.

조정 계층은 도메인에서 선택하기에 적합하지도 않고 도메인이 되기에도 적합하지 않으므로 각 도메인의 비즈니스 활동과 기능 간의 조정 부분을 무엇이라고 해야 할까요? 현재로서는 '상업적 역량', '솔루션'이라는 단어가 더 적절하다.

4.5 인터페이스 분리 원칙: 비즈니스 활동

인터페이스 분리 원칙은 다음과 같습니다. 클라이언트는 필요하지 않은 인터페이스에 의존해서는 안 됩니다. 다른 클래스에 대한 클래스의 종속성은 가장 작은 인터페이스를 기반으로 해야 합니다.

DDD에서 도메인 구성을 배우는 것 외에도 응용 프로그램 계층이 비즈니스 요청을 더 잘 수행할 수 있는 방법에 주의를 기울여야 하고 비즈니스 논리 분할의 기반을 연구해야 합니다.

인터페이스 분리 원리: 인터페이스 분리 원리

규칙이 없으면 돌아다니기 힘들어

이전에 사업부서에서 사업을 할 때는 사업 활동, 프로세스 등 관련 개념이 없었고, 사업상 필요에 따라 업무 스크립트를 자주 작성했는데 경험의 양이 코드의 우아함에 영향을 미쳤습니다. 그러나 경험과는 별개로 모든 사람은 응용 프로그램 계층의 다양한 비즈니스 논리를 수행하기 위한 더 나은 구조적 프레임워크와 원칙을 가지고 있지 않으므로 의심이 가득합니다.

• 외부 서비스 인터페이스는 어떻게 분할되어야 합니까?

• 유사한 서비스 간에 프로세스를 공유할 수 있습니까?

• 비즈니스 실행 프로세스를 어떻게 더 구조화하고 세분화할 수 있습니까?

• ......

표준화되지 않은 결과는 모든 사람이 종종 자신의 의견을 가지고 있다는 것입니다. 모두가 일련의 구조를 설정하기를 원하고 아무도 다른 집합에 동의하지 않습니다. 각각 고유한 코드 영역이 있습니다.

플랫폼의 안정적인 프레임워크

플랫폼이 오랫동안 생각하고 관리해 왔으며 상대적으로 안정적인 합의가 있기 때문에 현재 작동 중입니다. 비즈니스 입구와 비즈니스 입구 사이, 비즈니스 입구와 안정적인 로직 사이의 전체 디자인은 시나리오 기반 로직을 수행하기 위한 공간과 확장 기능을 예약하고 구조는 비교적 명확합니다.

• 입구는 비즈니스 활동에 따라 세분화됩니다. 서비스 입구는 비즈니스 활동에 따라 확장되며 코어는 사용 사례를 이해하고 주의를 기울이며 어떤 역할이 무엇을 해야 하는지 파악합니다.

• 프로세스 독립 실행 및 오케스트레이션: 비즈니스 활동은 멀티플렉싱 계층(예: 도메인 서비스, 외부 서비스 및 비즈니스 확장)에 도달하기 전에 독립적으로 유지되고 조정됩니다.

• 프로세스 파일의 도움으로 실행 프로세스를 정렬합니다. 실행 프로세스를 실행 노드로 분할하고 노드 분할은 "기능 포인트", "관련 도메인", "관련 엔터티" 등을 기반으로 할 수 있습니다. 노드 간의 공통 기능은 기본 기능에 속합니다.

• ......

반복된 검토는 합의를 형성합니다.

나누고 정복하고, 모두의 초점을 좁히고, 더 잘 나누고 협력하는 것은 정말 이해하고 받아들이기 쉽습니다. 그러나 합리적인 세분화를 위해서는 통일된 합의와 원칙이 있어야 합니다.

합의의 형성은 먼저 합의에 동의한 다음 분할하는 것이 아니라 초기 의사소통 후 분할을 시도한 다음 검토에서 합의에 도달하고 우여곡절 속에서 앞으로 나아가는 것입니다. 모든 사람의 견해와 갈등이 상대적으로 크다면 합의에 도달하는 과정은 상대적으로 느릴 것입니다. 다행스럽게도 이러한 종류의 세분화는 자주 발생하지 않으며 수요가 많고 리팩토링이 큰 경우이기도 합니다. 이때 확보한 연구 시간과 개발 자원도 충분하다.

4.6 종속성 반전 원칙: 육각형 아키텍처

종속성 역전의 원칙은 다음과 같습니다. 프로그램은 구체적인 구현이 아니라 추상 인터페이스에 의존해야 합니다.

DDD에서 언급한 육각형 아키텍처는 도메인 구성을 아키텍처의 핵심 목표로 삼아 추상 코어의 상태를 더욱 향상시킵니다.

의존 역전 원리: 의존 역전 원리

현장을 중심으로 삼는 것은 사실 상대적으로 중요한 변화입니다.

• 이전에는 계층화된 아키텍처를 기반으로 했습니다. 보기 수준에 주의를 기울이고, 기능을 낮추고, 더 많은 도구를 재사용하고, 공통 구성 요소를 축적하려고 했습니다.

• 이제 현장에 집중하십시오: 추상화 수준을 보는 데 집중하고, 이해를 현장의 핵심으로 통합하고, 더 많은 "이해" 재사용을 수행하여 비즈니스 지식을 축적하십시오.

이러한 변화를 통해 우리는 의식적으로 "영역 이해"를 핵심으로 삼고 산업 경쟁력을 형성하며 "지식"을 자산으로 판매할 수 있습니다.

도메인 커널의 추상화를 보장하기 위해서는 도메인 커널의 경계를 정의해야 하며 인터페이스에는 두 가지 유형이 있습니다.

• 업스트림에 제공되는 기능: 인터페이스 선언을 통해 가정할 수 있는 책임을 설명하고 도메인 내에서 지원을 구현합니다.

• 다운스트림 기능에 대한 종속성: 외부 서비스, 비즈니스 확장 사용자 정의 및 스토리지 서비스는 모두 다운스트림 서비스로 간주될 수 있으며 서비스 종속성은 인터페이스를 통해 선언됩니다.

도메인 코어와 외부 사이의 인터페이스가 분리되어 있음을 알 수 있습니다. 보다 기본적인 서비스의 경우 애플리케이션 계층에 속하는 비즈니스 입구와 동일한 외부 포트로 간주됩니다. 예를 들어 스토리지 서비스는 다음과 같습니다.

• 그것은 기본 기능에 관한 것입니다: 데이터 프레임 + DO, 변환을 이해할 필요가 없고, 변환이 업스트림에서 완료되며, DO도 업스트림에서 핵심 모델로 사용됩니다.모델 추종 전략을 채택할 때, 업스트림은 순환을 위한 핵심 개체로 DO를 완전히 사용합니다.

• 이제 "비즈니스 구성 요소"로 이해할 수 있습니다: 도메인의 스토리지 인터페이스를 구현하고 프로토콜 변환을 수행하고 도메인 개체를 데이터 스토리지 개체 ​​DO로 변환해야 합니다. DO는 도메인에서 직접 이해하지 못하지만 도메인 개체로 변환한 다음 외부 세계에 노출해야 합니다. 커널은 성능을 정의합니다.

이러한 종류의 아키텍처는 도메인 이해의 추상적인 핵심 위치를 설정하고 R&D 학생들이 비즈니스 문제에 대해 생각하는 데 더 많은 주의를 기울일 수 있도록 하며 " 핵심 비즈니스 문제에 가까운" 더 많은 "살과 피" 소프트웨어를 구축합니다. 기본 뼈대" , let us 고객의 가치에 더 가까이 다가가는 것은 소프트웨어 복잡성을 다루는 과정에서 더 인식되는 방향입니다.

V. 요약

DDD를 추구하는 것은 일련의 프레임워크가 문제를 분해하고 안정적이고 효율적인 생산 효율성을 얻을 수 있도록 안내할 수 있기를 바라며 다양한 비즈니스 문제를 우아하게 해결하려는 우리의 열망에서 비롯됩니다.

그러나 이것은 "영구 운동 기계"를 추구하는 것과 같으며 명확한 답을 얻기 어려운 과정입니다. 소프트웨어의 복잡성을 해결할 수 있는 솔루션은 관련 시나리오와 결합하고 지속적으로 진화해야 합니다.단순히 DDD를 추구하는 것은 "실버 총알"을 얻지 못합니다.

그러나 "영구 운동 기계"에 대한 연구와 마찬가지로 에너지 변환 과정에 집중할 수 있으므로 보다 효율적인 에너지 기계를 만들 수 있습니다. DDD를 연구하고 추구하면 비즈니스에 대한 깊은 이해에 더 많은 관심을 기울일 수 있으며 확장하기 쉬운 코드 구현을 작성할 수 있습니다.

프로그래밍을 도전으로 가득 채우고 모두가 프레임워크 연구에 열광하게 만드는 것은 "비즈니스의 지속적인 발전"과 "소프트웨어의 복잡성"의 존재라고 생각합니다.