インターネット上にはDDDに関する記事がたくさんありますが、それはもちろん良いことです。誰もがソフトウェア開発の問題を解決するための優れた設計手法を習得したいと考えています。しかし、いくつかの問題もあります。インターネットでDDDの記事をいくつか開くだけで、すべての著者がDDDのアイデアに従って設計されていると言っていますが、注意深い学生は、各著者のDDD記事の構造を見つけるでしょう。アーキテクチャ図は非常に異なります、あなたは非常に驚かれることでしょう、これらはすべてDDDデザインですか？実際、ここには問題があります。つまり、言葉やアイコンで抽象的な概念を説明する場合、大きな違いがあります。視覚障害者の概念を例えとして象に触れないでください。これは適切ではありません。2人の生徒がDDDに精通していて、数年間複数のプロジェクトを実践したとしても、彼らが書いたものはまだ異なります。私は少し早くJavaを始めました。もちろん、私は年をとっていて保守的だと言えます。最初はミドルウェアがそれほど多くなく、Struts 1.xMVCフレームワークに基づいて開発されたことを覚えています。設計ドキュメント異なる学生によって書かれたものも非常に異なります。このような単純なMVCアーキテクチャは、異なるアーキテクチャ設計ドキュメントを持つ可能性があり、DDDは比較的抽象的で理解しにくいため、アーキテクチャ設計ドキュメントの長さは同じではなく、理解できます。
では、「各著者によるDDDの解釈は同じである必要はない」という事実、および「DDD設計文書は異なる形式で提示できる」という事実を受け入れる必要がありますか？そうなると、DDDを学びたいという学生の負担が非常に大きくなります。どちらのデザイン表現方法が良いのか、わかりやすいのか、DDDが比較的オーソドックスで他人ではないことをどうやって知るのか。曲がっている。遊び心で考えることができないと言っているわけではありませんが、伝道の観点からは、理論的な事実を尊重する必要があります。
コードがビジネスやロジックを表現するときに実際の状況を反映できることは誰もが知っています。異なる開発者によって記述された場合でも、デザインパターン、命名規則、開発言語の制約などへの準拠を考慮すると、コードは一般的に同じで、便利です。理解してください。ユニットテストとコードレビューがあるとよいでしょう。これは、一部のドキュメントが完全ではなく、多くの学生がコードを読むことを選択し、一部の学生が「コードを直接見て、PPTとドキュメントを見てはいけない、誤解される、そうでなければわからない」と言う場合もあります。死ぬ方法」さらに、現在非常に優れたプラクティスは、Terraform for Infrastructure as Code、Kubernetes YAML for Platform as code、PlantUML for Diagram as Codeなど、Everything as Codeであることを誰もが知っています。DDDの概念を次のように使用できますか？コード、私たちのデザインをより統一し、デザインのアイデアを表現するのにより便利に、そして他の人に理解されやすくしましょう。
DDD DSL
DSLを使用することは、DDDをコードで表現することです。これは長い間存在していましたが、Sculptor [1]やhttp： //fuin.orgDDD DSL [などのDDDの戦術設計とコードレベルに傾いています。2]、誰もが一般的にそれがXtextに基づくDDDコードジェネレータであると信じています。いくつかのコードを生成するだけで、学ぶのに非常に多くの労力がかかります。それは単なるJavaコードであるため、一般的な注目は高くありません。
コード生成の部分に加えてDDDDSLを配置し、戦略的設計（Strategic Design）に傾倒して、設計のアイデアを強調することはできますか？それなら、DDD asCodeははるかに包括的です。次に、ContextMapperフレームワークを紹介します。
用語を説明する：多くの学生は、DDDの戦略的設計（戦略的設計）と戦術（戦術的設計）の違いについて疑問を持っています。DDDには、次のような特別な紹介があります。
- タクティックDDD：エンティティ、値オブジェクト、集計、ルートエンティティ、サービス、ドメインイベント、ファクトリ、リポジトリ。
- 战略設定计（戦略的DDD）：有界コンテキスト、コンテキストマップ; 公開言語、共有カーネル、オープンホストサービス、顧客サプライヤー、適合者、腐敗防止レイヤー（コンテキスト関係タイプ）。
実際、それは比較的単純です。戦略的設計はより大きく、より巨視的です。それは、会社の上級管理職、分業、さまざまなチームや製品の協力によって議論されたビジネスおよび技術的な方向性として理解できますが、戦術的な設計は比較的小さく、主にDDDのエンティティ、サービス、リポジトリなどの内部的なBoundedContextに集中し、可能なアプリケーション開発の技術的選択に加えて、技術レベルにより多くの注意が払われていると言えます。 。
ContextMapperフレームワークの概要
ContextMapperはオープンソースプロジェクト[3]であり、主にDDD戦略（戦略）設計、コンテキストマッピング（コンテキストマッピング）、BoundedContextモデリング、サービスデカップリング（サービス分解）などのDDD設計のDSLサポートを提供します。 ContextMapperに基づくDDDDSLの表現に基づいてプロジェクトを完了する方法について。
ContextMapperを紹介するときは、最初にプロジェクトの背景を説明しましょう。Ruhuaはアーキテクトであり、DDDに精通しており、いくつかのプロジェクトでDDDを実践しています。最近、彼はメンバーシップラインに参加し、会社のマイクロサービス設計のアイデアにより一致するようにメンバーシップシステムの変換を完了する責任があります。メンバーシップラインの前には、メンバーセンターが提供する多数のREST APIサービス、メンバー登録およびログインアプリケーション、個人パスワード、基本情報、SNSサードパーティのバインドおよび支払いの変更を処理するメンバーセンターの3つのアプリケーションがあります。メンバーログイン後のメソッドバインディング待機。
メンバーチームに参加した後、RuhuaはDDD + MicroServicesに基づくアーキテクチャのアイデアに基づいて全員とコミュニケーションを取り、全員が同意しましたが、特定のアーキテクチャの設計とドキュメントを実装する方法は誰にとっても困難です。最も典型的なDDD設計図を見てみましょう。
SubDomain、BoundedContext、Entity、ValueObject、Service、Repository、Domain Event、Context Mappingなどの概念は問題ありませんが、このアイデアを他の人にどのように表現するのでしょうか。毎回DDD設計図やレイヤード図を貼り付けて、DDDに従って設計していると言うことはできません。
サブドメインから開始
Ruhuaは、サブドメインの分割であるDDDの最初のステップを開始しました。もちろん、DDDには、Generic、Supporting、Coreの3種類のサブドメインが含まれています。これらの違いについて簡単に説明します。
- ジェネリックドメイン：ジェネリックドメインは通常、アーキテクチャ設計におけるロギング、メトリクス、トレースの可観測性、さまざまなクラウドサービス（クラウドサービス）など、業界によって解決された問題と見なされており、これらは比較的良好です。計画を実現し、接続するだけです。もちろん、ERP、CRM、成熟したハードウェアシステムなどの成熟した業界ソリューションなどのビジネスもあり、それらを購入することができます。
- サポートドメイン：一般的なドメインに似ていますが、システムはより内部的であるか、一般的にカスタム開発が必要です。たとえば、eコマースシステム、メンバーシップ、商品、注文、ロジスティクス、その他のビジネスシステム、そしてもちろん、社内で開発された技術サポートシステムもあります。
- コアドメイン：これは私たちがしばしばビジネスコアと呼ぶものです。もちろん、それが技術製品である場合、それは技術コアです。これはあなたが最も注意を払う必要があるものです。
これら3つの全体的な関係は次のとおりです。コアは最も特徴的で、より多くのエネルギーを消費します。複雑さYの次元では、複雑度の高い汎用ドメインとサポートドメインを回避する必要があります。これにより、注意が散漫になり、多くのエネルギー、本当に必要な場合は、サービスを購入する方法が最善かもしれません。
画像ソース：https：//github.com/ddd-crew/ddd-starter-modelling-process
Ruhuaはまず、アカウント関連のアカウントの処理、メンバーのマーキングのためのUserTagの処理、支払い方法の処理のためのPaymentProfileの処理、ソーシャルプラットフォーム統合のためのSnsProfileの処理、その他1つのプロファイルなど、メンバーをいくつかのサブドメインに分割します。ここではGenericは使用しません。 DomanのサポートとDomanのサポートの計画は、主にビジネスのコアドメインから始まります。学生は、次のように、PPTを使用して分割構造と開始点を説明しました。
ただし、一部の学生は、UMLコンポーネント図の方が優れているかどうか、および背後にあるUML図と統合すると便利であると次のように述べています。
もちろん、構造図を表示するためのVisioなどの他の多くのグラフィカルツールがあります。DDDの最初のステップ：サブドメインの分割と表示。理解にはさまざまな方法があり、説明方法とグラフィカルな表示方法には多くの違いがあります。
質問の最初に戻って、サブドメインを分割したいので、次のDSLコードも可能です。
Domain User {
domainVisionStatement = "User domain to manage account, tags, profiles and payment profile."
Subdomain AccountDomain {
type = CORE_DOMAIN
domainVisionStatement = "Account domain to save sensitive data and authentication"
}
Subdomain UserTagDomain {
type = GENERIC_SUBDOMAIN
domainVisionStatement = "UserTag domain manage user's KV and Boolean tag"
}
Subdomain PaymentProfileDomain {
type = CORE_DOMAIN
domainVisionStatement = "User payment profile domain to manage credit/debit card, Alipay payment information"
}
Subdomain SnsProfileDomain {
type = CORE_DOMAIN
domainVisionStatement = "User Sns profile domain to manage user Sns profile for Weibo, Wechat, Facebook and Twitter."
}
Subdomain ProfilesDomain {
type = CORE_DOMAIN
domainVisionStatement = "User profiles domain to manage user basic profile, interest profile etc"
}
}対応するDSLコードの構文はまだわかりませんが、ドメイン名、ドメインタイプ、ドメインビジョンステートメント（visionStatement）はわかっています。テーブルやグラフィックなどのシステムドメインの表示方法については、次のことができます。現在のデータに基づいて表示と見なされます。その中で、UserTagDomainタイプはGENERIC_SUBDOMAINであり、これはマーキングがユニバーサルドメインであることを意味します。たとえば、後の段階で製品、画像、またはビデオチームと協力し、全員が一緒にマーキングシステムを構築できます。
注：サブドメインには、タイプとdomainVisionStatementが含まれているだけでなく、エンティティとサービスを追加することもできます。その目的は、コア機能を強調し、ドメインの理解を容易にすることです。たとえば、resetPasswordとauthBySmsCodeをアカウントに追加します。ほとんどの人が信じています。これを知っているそれはどういう意味ですか ただし、VO、リポジトリ、ドメインイベントなど、他のオブジェクトをサブドメインに追加しないように注意してください。これらはすべて補助的な開発であり、BoundedContextで使用する必要があります。
Subdomain AccountDomain {
type = CORE_DOMAIN
domainVisionStatement = "Account domain to save sensitive data and authentication"
Entity Account {
long id
String nick
String mobile
String ^email
String name
String salt
String passwd
int status
Date createdAt
Date updatedAt
}
Service AccountService {
void updatePassword(long accountId, String oldPassword, String newPassword);
void resetPassword(long acountId);
boolean authByEmail(String email, String password);
boolean authBySmsCode(String mobile, String code);
}
}コンテキストマップ
ContextMapは、主に各ドメインの各BoundedContext間の関係を記述します。これは、BoundedContextのトポロジマップとして理解できます。ここではBoundedContextの詳細については説明しません。作成するHSFサービスアプリケーション、顧客のリクエストを処理するWebアプリケーションやモバイルアプリ、外部のSaaSシステムなど、ドメインを実装するキャリアとして理解する必要があります。家賃。たとえば、システムにブログのサブドメインがあり、それを自分で開発したり、WordPressを設定したり、Mediumを使用してブログを実装したりできます。マイクロサービスのシナリオに戻りますが、マイクロサービスアプリケーションを分割する方法は？サブドメインはビジネスドメインまたは仮想ドメインに対応しますが、BoundedContextはサブドメインを具体的にサポートするマイクロサービスアプリケーションです。もちろん、1つのサブドメインが複数のマイクロサービスアプリケーションに対応する場合もあります。
各BoundedContext関係が記述されているため、DDDが推奨するパートナーシップ（[P] <-> [P]）、共有カーネル（[SK] <-> [SK]）、顧客/サプライヤーなどの関連関係が必然的に含まれます。 （[C] <-[S]）、Conformist（D、CF] <-[U、OHS、PL]）、オープンホストサービス、腐敗防止レイヤー（[D、ACL] <-[U、OHS、PL]） 、公開言語など、詳細な紹介についてはDDDの本を参照できます。これらの対応する関係には、括弧内の表現方法である対応する略語があります。これは、関連関係のチートシートの説明図です。
画像ソース：https：//github.com/ddd-crew/context-mapping
これらの関係を表現するために自分で絵を描く場合、矢印の種類や備考など、多くの作業が必要になります。そうしないと、誤解を招くことになります。ここでは、ContextMapper DSLによるContextMapの説明に直接移動します。コードは、次のとおりです。
ContextMap UserContextMap {
type = SYSTEM_LANDSCAPE
state = TO_BE
contains AccountContext
contains UserTagContext
contains PaymentProfileContext
contains SnsProfileContext
contains ProfilesContext
contains UserLoginContext
contains UserRegistrationContext
UserLoginContext [D]<-[U] AccountContext {
implementationTechnology = "RSocket"
exposedAggregates = AccountFacadeAggregate
}
ProfilesContext [D]<-[U] UserTagContext {
implementationTechnology = "RSocket"
exposedAggregates = UserTags
}
UserRegistrationContext [D,C]<-[U,S] UserTagContext {
implementationTechnology = "RSocket"
exposedAggregates = UserTags
}
UserRegistrationContext [D,C]<-[U,S] SnsProfileContext {
implementationTechnology = "RSocket"
}
}マップに含まれている各BoundedContextの名前を確認し、それらの間の関係を説明できます。関連付け関係の説明には、対応する説明が含まれます。先ほど、BoundedContextがドメインの特定のシステムとアプリケーションの担い手であるため、対応する技術的な実装が含まれることを説明しました。HTTP REST API、RPC、Pub / Subなど、ブログシステムがMediumの場合、implementationTechnology = "RESTAPI"。また、クラスオブジェクトやフィールド、サービスインターフェイスなど、公開された集計情報を表すexposedAggregatesもあり、2者間の通信を容易にします。これをBoundedContextで紹介します。
BoundedContext
ContextMapでは、それらの間の関係を記述してから、BoundedContextを詳細に定義する必要があります。ほとんどの学生は、Entity、ValueObject、Aggregate、Service、Repository、DomainEventなどのBoundedContextに含まれるコンテンツを知っていると思います。誰もがこれに精通している必要があります。ここでは、BoundedContextのContextMapperコードを次のように示します。
BoundedContext AccountContext implements AccountDomain {
type = APPLICATION
domainVisionStatement = "Managing account basic data"
implementationTechnology = "Kotlin, Spring Boot, MySQL, Memcached"
responsibilities = "Account", "Authentication"
Aggregate AccountFacadeAggregate {
ValueObject AccountDTO {
long id
String nick
String name
int status
Date createdAt
def toJson();
}
/* AccountFacade as Application Service */
Service AccountFacade {
@AccountDTO findById(Integer id);
}
}
Aggregate Accounts {
Entity Account {
long id
String nick
String mobile
String ^email
String name
String salt
String passwd
int status
Date createdAt
Date updatedAt
}
}
}BoundedContextの別の説明は次のとおりです。
- 言うまでもなく、BoundedContextの名前は、ContextMapの名前と同じです。
- AccountDomainの実装：実装するサブドメインを示します。サブドメインに複数のBoundedContextが含まれる場合があることは誰もが知っています。これらのBoundedContextは連携して、サブドメインのビジネス要件を完了します。ContextMapは、BoundedContextがいくつかのユーザーケースを実装する必要があることを示すための改良も提供し、公式ドキュメントには対応する指示があります。
- BoundedContext：typeの属性フィールドは、APPLICATION、SYSTEMなどのタイプを表します。domainVisionStatementは、BoundedContextの責任について説明しています。ImplementationTechnologyは特定のテクノロジーを表します。BoundedContextには特定のアプリケーションとシステムが関係していることを前述したので、対応する技術ソリューションの実装について説明し、コア部分について説明する必要があります。responsibilityは、BoundedContextの責任のリストを表し、ここではキーワードのみが必要です。たとえば、Accountはセキュリティ検証を担当します。
- AccountFacadeAggregate：DTOのオブジェクトの定義、サービスインターフェイスの定義など、外部呼び出しに提供される集計を表します。
- アカウントの集約：これは、エンティティ、値オブジェクト、サービスなどのBoundedContextの内部集約を表します。ここで説明するために、DDDのAggregateはエンティティオブジェクトと値オブジェクトの集約オブジェクトであり、ContextMapperのAggregateは、サービスコレクションなどの一部のリソースのコレクションを表します。
BoundedContextの詳細については、スカルプタードキュメント[4]を参照できます。実際の状況に応じて、DomainEvent、Repositoryなどの対応するパーツを追加できます。
個人的には、BoundedContextはまだユビキタス言語に関与しておらず、対応する補助設計ドキュメントが必要であり、関連するプロジェクトの背景や技術的な決定などを説明する必要があると感じています。個人的には、C4アーキテクチャ設計の作者が書いた「ソフトウェアアーキテクチャの視覚化、文書化、探索」[5]をお勧めします。これは非常に実用的です。DDDアーキテクチャ設計文書としては、まったく問題ありません。
記事の冒頭で、以前のDDD DSLはコードジェネレーターであると述べました。コードジェネレーターの場合、生成されるコードには、エンティティ、値オブジェクト、サービス、リポジトリによって保存されたディレクトリ。、生成されたコードには、特定の注釈またはインターフェイス、標準フィールドなどが含まれる場合もあります。もちろん、ここではコードジェネレータの問題については説明しませんが、すべてのDDDアーキテクチャ設計が特定の標準化されたディレクトリ構造を採用していることを願っています。すべての人が推奨するいくつかの標準を次に示します。
- ddd-4-java：Javaを使用したDDDの基本クラス[6]
- jDDD：開発者がJavaコードでDDDビルディングブロックを表現するのに役立つライブラリ[7]
- ddd-base：java [8]のDDD基本パッケージ
実際、これら3つの開始点は同じです。つまり、コードレベルでDDDを記述します。コアは、いくつかのアノテーション、インターフェイス、基本クラス、そしてもちろん推奨されるパッケージ構造です。
ContextMapperの他の機能
これについて言えば、実際、DDD全体として、ドメイン分割、BoundedContextトポロジ図とドメイン全体の関連付け関係、BoundedContext固有の定義、およびアーキテクチャ設計ドキュメントの仕様について明確に説明しました。しかし、ContextMapperはUserStoryとUseCaseに対応するDSLも提供します。見てみましょう。
UserStory
多くの学生がUserStoryの書き方を尋ねました。このDSLを使えば、学生はUserStoryの書き方を心配する必要がなくなります。このDSLは比較的明確で、主に3つの要素があります。「aaa」として「xxx」ができることを望んでいます。「yyyy」ができることを望んでいるため、「zzz」もUserStory：役割、活動、および商業的価値。
UserStory Customers {
As a "Login User"
I want to update a "Avatar"
I want to update an "Address"
so that "I can manage the personal data."
}使用事例
ユースケースは、要件を説明する方法です。UML図には対応するユースケース図があります。コアはアクター、インタラクティブアクション、および商業的価値です。対応するDSLコードは次のとおりです。
UseCase UC1_Example {
actor = "Insurance Employee"
interactions = create a "Customer", update a "Customer", "offer" a "Contract"
benefit = "I am able to manage the customers data and offer them insurance contracts."
}Aggregateでは、次のように、useCasesプロパティを設定して、対応するUseCaseを記述することができます。
Aggregate Contract {
useCases = UC1_Example, UC2_Example
}ContextMapperの利点
あなたの声明によると、DDDを説明するためにDSLコードを使用していますが、これにはどのような利点がありますか？
アーキテクチャ設計の標準化
このコードメソッドは一目でわかりやすく、非常に標準化されています。コードが間違っていると、もちろん問題が発生します。コンパイルは失敗し、IDEがコードの修正を支援します。したがって、DDD DSLは同じであり、完全に明確です。現在、ContextMapperDSLにはEclipseおよびVSCodeプラグインが含まれています。IntelliJIDEAは、ファイルタイプとライブテンプレートをカスタマイズすることにより、cmlファイルの作成を支援します。
ジェネレーターのサポート
先ほど、コードの生成に役立つDDD DSLサポートコードジェネレーターについて説明しました。DDDDSLコードは標準であるため、誰もが理解できると思います。このコードモデルに基づいて他の形式のコードを生成します。もちろんこれで問題ありません。
さらに、ContextMapperは、ContextMapのグラフィック表示やPlantUMLの構造図など、他のモデルの生成もサポートしています。対応するコードはここにあります[9]。スクリーンショットをいくつかあげましょう：
もちろん、ContextMapperは、DDD DSLモデルに基づく一般的なジェネレーターとFreemarkerテンプレートも提供します。その後、ファイルスキャフォールディングをすばやく作成するためのJHipsterドメイン言語（JDL）の生成など、必要なすべての種類の出力を生成できます。 。多くのJavaプログラマーはこれに精通していると思います。Webアプリケーションを開発するときは、Freemarkerを使用してHTMLを生成します。詳細については、こちら[10]をご覧ください。
実際のDDD設計プロセス
アーキテクチャ設計を説明するDDDDSLがありますが、それは包括的で十分であり、開発は問題ではありませんか？まだ、ソフトウェアアーキテクチャの設計とコーディングの前に、需要調査、顧客訪問、ドメインエキスパートのコミュニケーション、需要分析、セミナーなどがあることを私たちは知っています。これは実際の生活では依然として不可欠であり、その目的はアーキテクチャ設計のフォローアップです。材料を提供し、道を開きます。では、DDDをこれらの予備操作と統合する方法は？実際、DDDには、EventStormingカードなど、この側面に関連するコンテンツがあります。
バウンドコンテキストキャンバスカード：
要件分析の段階でこれらのDDDカードの使用に注意を払うと、その後のDDD設計には、もちろん、UserStoryやユースケースなど、より優れた資料が含まれるようになります。
個人的な提案：時間があれば、DDDに関連する非常に包括的な最新の実用的な知識と実践のためにddd-crew [11]に注意を払うことを強くお勧めします。
DDDとマイクロサービスの関係
それはDDDDSLとは何の関係もありません。マイクロサービスアーキテクチャの設計は、複雑なビジネスシステムを緊密に連携するマイクロサービスアプリケーションに分割する方法にあります。分割の基礎は非常に重要です。SubDomainはビジネスの観点からビジネスの境界を分割し、BoundedContextはビジネスドメインに対応するアプリケーションベアラに焦点を合わせます。Generic BoundedContextは、同時に複数のサブドメインをサポートできるため、さまざまなビジネスシステムのアプリケーションの再利用が可能になります。クラウドネイティブのシナリオでは、システムタイプBoundedContextをさらに使用する、つまり、クラウドでシステムを再利用することで、独自の開発および保守コストを削減したいと考えています。BoundedContext of Appplicationタイプに戻ると、これは具体的に開発したいアプリケーションであり、どのマイクロサービスフレームワークを選択するかは、自分で決めることができます。プロセス全体を通じて、DDDはアプリケーション分割の理論的基礎の役割を果たします。
しかし、ここには別の問題があります。それはマイクロサービス間の通信の問題です。強力な分散アプリケーションを構築する必要があることを繰り返し強調できますが、推奨されるテクノロジースタックは何ですか？どうやるか そして、私たちはもっとうまくやる必要があります。これは明確に述べられていないので、誰もがREST API、gRPC、RPC、Pub / Subなどの混合通信テクノロジースタックを選択します。
DDDは、BoundedContext（パートナーシップ、c / s、共有カーネルなど）間の関連付け関係について説明されていますが、コミュニケーションとコラボレーションに固有であり、理論的な根拠はありませんが、DDDにはいくつかのコンセンサスもあります。コミュニティは、非同期メッセージ通信に基づいています+イベント駆動型の方が優れたソリューションであるため、DDDのチーフエバンジェリストであるVaughnVernonがDDD + Reactiveについて繰り返し話しているのを見ると、ContextMappingの通信の問題を解決することです。
そうは言っても、ContextMapperがMDSL（Micro-）Service Contracts Generatorの出力をサポートしていることがわかった場合、それは驚くべきことではなく、当然のことです。
マイクロサービスとDDDの関係の詳細については、「マイクロサービスはドメイン駆動設計を愛している、その理由と方法」[12]を参照してください。
総括する
ContextMapperによって提案されたDSLの概念は、依然として非常に優れています。少なくとも、誰もがDDDを理解する際のあいまいさを軽減できると同時に、標準化されています。DDD初心者のしきい値も低くなっています。ただし、アーキテクチャ設計のポイント、少なくとも読んで理解することはバリアフリーです。この記事の執筆時点で、ContextMapper DSLバージョン5.15.0がリリースされ、関連するすべての機能が開発されており、それでも非常にスムーズに使用できます。もちろん、実際の開発では、コードとしてのDDDが有効かどうかにかかわらず、DDDの練習をしている学生から貴重な意見が得られることを期待しています。
もちろん、私の記事ではContextMapperを明確に説明することはできません。contextmapper[13]には非常に詳細なドキュメントと対応する関連論文があります。もちろん、DSLのアイデアセットを使用する必要はありませんが、これらのアイデアと関連資料は重要です。 DDDへ。デザインはまだ非常に役に立ちます。
また、個人的にはDDDの初心者なら、ContextMapperの方が適していると思います。DDDは方法論です。これらの本は退屈です。眠くならずに2つの章を見るのはほとんど難しいです。逆に、DDD DSLを習得すれば、はるかに簡単になります。このDSLがどれほど複雑であっても、習得するプログラミング言語よりも複雑になることはありませんよね。それどころか、このDSLは非常に単純です。単純なDDD DSLを学習することで、概念、アイデア、および方法をすばやく理解できます。それが機能しない場合は、他の人のコード（DDD DSLの例）を見てください。また、これらの方法論を習得し、後でそれらを統合するために本や記事を使用することも非常に良いことです。
この記事はAlibabaCloudのオリジナルのコンテンツであり、許可なく複製することはできません。