2018-06-17 【メモ】DDD実践ドメイン駆動設計 第1章と第2章 実践ドメイン駆動設計の第1章と第2章を読んだメモ。 DDDへの誘い DDDとは何か ユビキタス言語を使って表現されたドメインのモデルをドメインエキスパート共に作り上げ、そのモデルを反映したソフトウェアを作る手法 ドメイン 組織が行う事業やそれを取り巻く世界 ユビキタス言語 開発チームとドメインエキスパートが全員合意の上で決定された、ドメインを取り巻く言葉。 ユビキタス言語は、「境界付けられたコンテキスト」内で閉じている 同じ言葉でも、コンテキストが違えば意味が異なる。業務で使う言葉にはそういう性質がある。 ドメインエキスパート システム化する業務に精通した人。 DDDの大きな目的は、ドメインエキスパートの持つ知見をシステムに取り入れることで、実際の業務を忠実に再現したモデルの上にシステムを作り出すこと。 ドメインモデル ユビキタス言語を使ってドメインオブジェクトの振る舞いを記述したもの DDDの利点 ドメインエキスパートと開発チームで業務知見を共有できる。 開発を通して業務を改善する方法を見いだせる。 業務上の戦略の変化に対応できるようになる。 ドメインエキスパートと認識の祖語が起きにくくなる。 ドメインオブジェクトの仕様を確認してもらえば、ドメインエキスパートがロジックに誤りがないことを確認できる。 ドメインの変化、後から手に入れた業務知見をコードに取り入れられる。 最初から完璧なものを作る必要が無い。 DDDの課題 ドメインモデルの構築にはそれなりに時間がかかる。 ユビキタス言語、ドメインエキスパート サブドメイン ドメインの一部分 基本的に業務やモノ単位で分割する。ただし、ドメイン分割に明確なルールは無い。チームで合意をとって決める。 コアドメイン これがないと事業が成り立たないようなサブドメイン。 境界付けられたコンテキスト 特定のモデルを定義・適用する境界を明示的に示したもの。 代表的な境界の例は、サブシステムやチームなど。
