DDD
概要
ドメイン駆動設計
顧客と開発者が共通言語で会話して、一体感あるチームとして、事業価値の高いソフトウェアを開発する手法
アジャイル前提
ソフトウェアとは現実の問題を解決するためのもの。なので、特定のドメインからソフトウェアは生まれる。
ドメインに適合した良いソフトウェアを作る良い方法はドメインの反映としてのソフトウエアを作ることです。
そのためには、まずドメインを理解しなければいけないのでDDDでの開発はドメインを知ることから始まる。
そして、ドメインを抽象化してドメインモデルを作る。
ドメインの専門家と対話をすることでドメインについての知識とモデル化をしていく。
DDDでやるべき背景
システム開発が複雑化してきて、ビジネス的にも俊敏な変更が求められるようになってきている
選択基準
現在複雑である
将来複雑になる
原則
コアドメインに集中
ドメインモデルの探求
境界づけられたコンテキストの内部でユビキタス言語を語る
重要なポイント
コアドメインに注力すること
DDDでは設計がコードであり、コードが設計
DDDでの開発の流れ
ドメインを理解する
ユビキタス言語を見つけてドメインモデルを作る
モデルをコンテキスト境界で分ける
モデル駆動設計
コードに落とし込む
DDDが解決すること
システム設計、詳細設計と設計が二つあってコードとの同期が取れなくなる問題
ビジネス価値
変更容易性
従来のトランザクションスクリプト的実装では変更が難しい
hiroki.icon DDDの適用は大変で難しくなるしコストも大きくなるが、そもそも変更容易性を保ちつつビジネス価値を発揮し続けるソフトウェアというのは困難なもので相応の労力がかかるのは当然なのだ
メモ
コードを対象としたリファクタリングはパターン化できますし、組織化し体系 化することができます。しかし、モデルに対する、さらに深い洞察を得るため のリファクタリングはそうはいきません。パターンを作ることができないので す。モデルは複雑で様々な形態をとります。したがって、機械的な方法でモデ リングに取り組むことはできません。よいモデルは深い思慮と洞察、そして経 験と直感によって生み出されるのです。
アルゴリズムに書き下すことができない事はセンスの比率が高くなるという風に考えているのでやはり、良いモデリングをすることはセンスが問われるのかなぁ
どのようなドメインでも様々なモデルで表せます。そしてどのようなモデルで も様々な方法でコードに落とし込める