DDD Quickly

https://gyazo.com/1751f27cb9f47392b919db5db23a1543

🔖 2020/09/06

§1 ドメイン駆動設計とはなにか

設計大事、つくるもののドメイン大事

ソフトウェアは現実のドメインのモデル化

ドメイン: e.g. 銀行

ドメインモデル: 抽象 e.g. 関心の全体, プロジェクト関係者にむけて表現, 共有しなければいけない

ドメインモデルを表現 -> コード設計(User クラス作れる)

コード設計 < ソフトウェア設計

ドメインの知識を構築する

ドメインエキスパートから知識を聞く

§2 ユビキタス言語

🔖 2020/09/07

ドメインの専門家と開発者は言葉とかが違う

-> ドメインモデルに基づく言語「ユビキタス言語」を使う

e.g: 飛行機: 航路, 運行定点, 運行計画

図や文書を使って表現(UMLも)

§3 モデル駆動設計

NG: ドメイン-> お客さんのモデル(設計を念頭に置いてない) -> 開発者のモデル

ドメイン -> ユビキタス言語 -> モデル -> 実装

OOP使おう

レイヤアーキテクチャ

User Interface -> Application -> Domain -> Infrastructure

エンティティ

IDとかで一意なオブジェクト

バリューオブジェクト

一意性が無いオブジェクト e.g. Point

変更不可能、バリューオブジェクトやエンティティの参照を入れられる

サービス

どのエンティティにも属さない操作

モジュール

ドメインより大きい

通信的凝集: 同じデータの操作の集まり

機能的凝集: モジュール内にまたがって一つのうまく定義されたタスクを実行する場合

アグリゲート

多対多 -> 一対多

双方向の関連 -> 一方向の関連

ファクトリ

リポジトリ

ドメインからインフラストラクチャのコード分離するために

データのCRUDを提供

§4 リファクタリングのための更に深い洞察

モデルに対するリファクタリング

名詞はクラスになり、動詞はメソッドになる

🔖 2020/09/7

§5 モデルの完全性を理解する

複数チームにまたがる開発の場合モデルがずれると終わる.

モデルを意識的に分割して制約を守る

コンテキスト境界はむやみに変更してはならない

全員がオブジェクト間の関係を完全に理解している必要がある

モデルは最初から完璧ではないので継続的に統合していかなければいけない. (テストとかで)

コンテキストマップ

モデル同士の関係を記述したドキュメント,各モデル名はユビキタス言語の名前を持っている.

共有カーネル

密接な関係にある複数のアプリケーションを複数のチームで開発する場合統合にオーバーヘッドがかかる

-> ドメインモデルのある部分を共有し、どちらのチームもその部分のコードの設計を共有して開発する

カスタマー - サプライヤ

e.g. Webショッピングシステム(サプライヤ)とレポーティングシステム(カスタマ)

顧客と技術者の関係: コンテキストの境界を合わせる

順応者

カスタマがサプライヤに寄せに行く

防腐レイヤ

外部システムとはネットワークかデータベースによって連携される

レガシーな外部システムのモデルから自分のモデルを守るために層を挟む(アダプタ的な)

サービスとして実装するのあり(ファサードパターンとしてデザインするのげ現実的)

別々の道

統合する以外の方法、共有部分がほとんどないときとか

公開ホストサービス

外部サブシステムが複数のサービスから使われるときは別サービスとする(マイクロサービス的な?)

蒸留

おおきいモデルを見つめてコアのドメインと分けられたドメインにする

コアドメインを担当するのは最も優秀な人

DSL: DDDの次の大きな一歩

完