Domain Driven Design (ドメイン駆動開発)

資料

DDDには3つの領域がある開発思想、戦略的設計、戦術的設計

それぞれ、思想、ミクロ、マクロ

それぞれ、どうやってドメインをアプリケーションへ落とし込む、どうやってコードを書くか、全体の構造

ドメインの知識を表現していないモデルをドメインモデル貧血症と書いている

トランザクションスクリプトとも

モデル単体で不変条件を常に守れるように書く、ということ？

Ubiquitous Language（ユビキタス言語）パターン

プロジェクトに関わる人全員がわかる、専門用語を使っていくということ

コードによって記述したい

Model-Driven Design（モデル駆動設計）パターン

決めたユビキタス言語をコードに反映させよう、ということ

ドメインモデルとコードがお互いに反映されあう

Hands-On Modeler（実践的モデラー）パターン

チームのすべての開発者は、プログラムを書くモデラーでなければならない。

MDDの好循環を生み出すために必要

難易度

Entity

IDを識別できるもの、DBに入ってるものは大体そう

ValueObject

IDがつかないやつ

スタジアムの指定席はEntity、その他の空席はValue Object

インフラ層: DAO、実際のデータの出し入れ

コンテキストを意識する

関数型言語で DDD を実装するときのテクニックについて

実装の話中心なのであまり DDD 感はなかったが、名前をつけてよくまとめられていると思う

関数型で中規模以上のアプリケーションを作るときには参考にしたい

ただ、トランザクションやエラー処理が絡んでくるとどうなるか気になった