コードで理解するDDDの戦略的設計・戦術的設計のつながり勉強会メモ

だいぶ経ってしまったが8/4（土）にDDDの勉強会に参加してきたのでその時のメモまとめ 講師は現在ビズリーチに在籍されている松岡さんで、自分も本人とは気づかぬうちにDDD関連の調べ物をしている際にブログを拝見させていただいたことがある方でした。 当初の予定よりも30分延長してくださり3時間半の長丁場で内容の濃い勉強会でした

DDD

まずは原典にあたってみるのが良い https://domainlanguage.com/ddd/reference/

設計したモデルとコードを一致させる モデルと実装の変更に耐えられる設計でないといけない -> これを実現するのが戦術的設計

モデルとは

対象領域の特定の側面を表現し、関連する問題を解決するために使用する対象物 ユビキタス言語でモデルを表現する

知識

問題領域の知識(Why,What)

お客さんの業務 ユーザのニーズ 市場 ->聞く、情報収集をする、フィードバックをもらう

解決領域の知識(How)

ツール、ライブラリの使い方 コード文法 ->実際に試して得る

境界づけられたコンテキスト

特定のモデルが適用される境界

戦略的設計

コンテキストを定義、再配置するなど？

戦術的設計

構成的にやりやすい形にするための設計？

アーキテクチャ

レイヤードアーキテクチャ

3層アーキテクチャなど Infra層がAppやDomainに依存する　-> DBを差し替えたりなど出来ない

ヘキサゴナルアーキテクチャ

オニオンやクリーンはこれの派生 ポートとアダプターで外部サービスとやりとり？ 外側は交換可能だが、中心はそんなに変わらない

オニオンアーキテクチャ

infra層が一番上に持ってこられるアーキテクチャ　-> infra層がAppやDomainに依存しない マイクロサービスなどで用いられている(サービス同士のhttp通信などはinfra層同士のやりとり) https://dzone.com/articles/onion-architecture-is-interesting

クリーンアーキテクチャ

ドメイン層

ドメインサービス

ドメインサービス

個体で扱えない、集合体で扱うものなどに利用（部屋の空き時間を知る場合は各予約単体では分からないため予約の集合体から空き時間を確認する必要がある） ただ、極力使わないようにするべき

ファクトリ

ドメインモデル

エンティティ

可変 IDを持つ IDで比較する 1テーブルに相当

値オブジェクト

不変 IDを持たない 値で比較する テーブルの値に相当

ドメインイベント

集約

整合性を保つ単位？　-> トランザクションで整合性を保証する単位？ 1repository1集約 1つのコンテキストの中に複数の集約がある

マイクロサービス

マイクロサービスはコンテキスト単位