XP祭りでDDD勉強会のセッションやります(その２)
https://confengine.com/conferences/xp2021/proposal/15656/xp
当日は講義形式というより勉強会スタイルで一緒にこのサイトを読みながら学ぶを予定しています。
前回に引き続き予習です。
4Cモデリング
４Cモデリングは、C4モデルは、1:Context(コンテキスト)、2:Containers(コンテナ)、3:Component(コンポーネント)、4:Code(コード)の４つCのレベルで整理するライトなモデリング手法です。
４Cモデリングは、DDDのためのモデリング技法ではないです。が、DDDと相性が良い箇所もあると感じました。集約ルートの境界のAPIや集約内部の構造を明らかにするのには4:Codeレベルのモデリングが役立つでしょう。 境界づけられたコンテキストを表現するに、マイクロサービスの場合は２:Conteainers、モジュールモノリスの場合は3:Componentで図解し境界を明らかにすることになるでしょう。ただ、構成要素の構造ではなく、ステークホルダーを巻き込んで、ビジネス上の時間軸で、境界づけられたコンテキスト＆集約の全体像を掴みたい理解を深めたいなら、Event Stormingのワークのほうが有利に働きそうです。
CQRSパターン
Command（状態更新系）とQuery（参照系）のモデルに差異があるなら、モデル自体を分離する方法としてCQRSパターンが知られています。 DDDの文脈ではAggregate（集約）をWriteモデルと割り切ってしまって、Readモデルは別途用意することがあります。
Command系の例
Write系は、Repositoryを経由して、Aggregateにアクセスし、状態変更しています。
Query系の例
軽く読んでいると、Read側はDapparとDtoで参照モデルを返却しているようです。
CQRSについてはこちらも
Event Sourcing
Paymentの箇所は、事実の残すを重視のためか、Event Sourcingを採用しているようです。Event Sourcingは、一連のDomain Eventを記録することで状態を管理する方法です。最新のAggregateの状態は、Domain Eventを組み立てるとわかります。メタファですがバージョン管理システムで最新のソースコードは一連のコミットを適用すれば組み立てることができますがそれに似たものです。
EventのWrite側
AggregateのAPI経由で、イベントを介して状態を更新し、Eventを記録している箇所例 です。
MeetingFeePayment#Create
MeetingFeePayment#Expire
MeetingFeePayment#MarkAsPaid
Apply箇所でEventを使ってAggregateの状態を更新し、AddDomainEventでイベントを保持し、あとでEvent Storeで永続化します。(が、インフラのコードは追えていない！)
最新のAggregateはEventから組み立てます。
Read側
Event Sorucingは、CQRSと組合わせて、状態変更はEventから組み立てたAggregateからEventを記録し、最新のReadModelは、Projectorを介して事事前に記録したものを参照するでしょうか？（ちょっとここは読んでて私も自信がないです。）
Event Sourcingについてはこちらを
うーん。Event Sourcingのインフラ側の仕組みコードは振り切られ気味です >_ <。
次はテストを観ておきましょう。（続く）
