freks blog

DDDを知っておきたくて、手始めとして
Domain Driven Design（ドメイン駆動設計） Quickly 日本語版
を読みました infoQアカウントを作れば無料で手に入ります（感謝）

以下、読んでみてのメモでほぼ自分用です
メモを見て内容が頭の中に浮かぶことを目標にしてます

=== メモ ===

ビジネスドメインが分かる人、開発者でユビキタス言語を作っていく

• 簡単にはつくれない

　- すべての必要な要件をすぐに出せる人はいない

• 開発者がいないとシステムで実現不可のものができあがることがある

4つのレイヤー

• user interface
• application
• domain
• infrastructure

エンティティ

• 一意性を持つものとして分類できるオブジェクト
  • idとかでuniqueにする

バリューオブジェクト

• 一意性はいらなくて、属性がほしい
  • 一意性を確保する必要ないのでパフォーマンスがよい

サービス

• どのオブジェクトにも属さない振る舞いをもつ
  • 銀行口座から相手の銀行口座へ送金するとき、送金機能はどちらの銀行口座にも持たせるのはおかしい
  • OOPだと必ず振る舞いはオブジェクトに属するためできない
• 内部に状態を保持しない
• エンティティ、バリューオブジェクトのための機能をまとめる
• 操作を提供するインターフェースになる

モジュール

• 巨大になったドメインモデルからモジュールを見つけて分離する

（上の4つとは異なるモデリングの難題に対応するため↓）
アグリゲート

• データの変更に対して一括して扱うことができる
• ひとつのルート（エンティティ）を持ちます
• 外部にあるオブジェクトがルートの参照しか保持できない

ファクトリ

• オブジェクト作成の複雑な操作をカプセル化するのに役立つ

リポジトリパターン

• オブジェクトの参照を取得するのに必要なロジックをすべてカプセル化する

リファクタリングを行うとドメインに対しての新たな洞察を得られることもある

モデルが満たさなければならない第一の条件は、矛盾がなく一定の用語が使われていて首尾一貫していること モデル

• コンテキスト境界
• 継続的な統合
• コンテキストマップ
• 共有カーネル

スタマ-サプライヤ

• 順応者

防腐レイヤ -> デザパタのFacade patternで作るのが現実的

• 別々の道

公開ホストサービス

• 蒸留
  • コアドメインを見つけ出す
  • 担当するのは最も優秀な人がいい

=== メモ終わり ===

DDDのさわりを知ることができた
実装のイメージがはっきりしてないので、積ん読してる

• エリック・エヴァンスのドメイン駆動設計 電子書籍｜翔泳社の本
• 実践ドメイン駆動設計（髙木正弘 ヴァーン・ヴァーノン）｜翔泳社の本

を読んでいきたい