こないだまで参画していたプロジェクトがDDDで設計されていた(と思われる)ものの、DDDがどういったものかよくわかっておらず「このクラスの実装これでええんか??配置する名前空間はここでええんか??」みたいなのが常にあって困った。プロジェクトは終わってしまったけどモヤモヤしっぱなしだったので読んだ。

DDDはなんかよくわからない用語が沢山出てきそうで難しそうだし、有名なエリックエヴァンスの本を途中まで読んで止めたという人を複数人知っているので、どうやって始めようか悩んだものの、評判のよさそうな入門書があった。


ドメイン駆動設計入門 ボトムアップでわかる! ドメイン駆動設計の基本


そんなに難しいことは書かれていなくて、ゆっくり読めば十分理解できる内容だった(ただしいつものごとく読んだからといって内容を覚えているとは言ってない)

書籍内のソースコードは珍しく(?)C#で個人的にはありがたかった。コードはGitHubに上がっており、後で自分が参照するためにこの記事にリンクをはっておく。ライセンスは翔泳社が保有しているので注意。

nrslib/itddd

以下、読んだ内容を簡単にまとめて置く。

用語的なの


  • モデリング: 概念を抽象化すること
  • ドメインモデル: ドメインの概念を抽象化したもの
  • ドメインオブジェクト: ドメインモデルをソフトウェアで動かすモジュールとして表現したもの
  • 値オブジェクト: システム固有の値を表す。不変、交換可能、等価性で比較される
  • エンティティ: ライフサイクルが存在するオブジェクト
  • ドメインサービス: オブジェクトに記述できない処理を書く
  • ドメイン貧血症: ドメインサービスに処理を書きすぎて処理がなくなった状態のドメインモデル
  • アプリケーションサービス: 超絶雑に書くとエントリーポイントに近い
  • LCOM: 凝集度の計算式
  • IoC Container = DI Container
  • アスペクト指向プログラミング: アノテーションなどを使ってコードに変更を加えずに(???)処理を追加する
    • アノテーション書いて時点で変更されたことにならないのだろうか?

設計的なの


  • 値オブジェクトやエンティティにふるまいを持たせる
  • アプリケーションサービスにドメインのルールを書かない
  • インスタンス変数は全てのメソッドで使用されるべき
  • 凝集度を高めるためにはクラスを分割するのがはやい
  • ビジネスロジックが特定の技術基盤に依存するのは避ける

アーキテクチャ


下記3つはどれもDDDのアーキテクチャ

  • レイヤードアーキテクチャ
  • ヘキサゴナルアーキテクチャ
  • クリーンアーキテクチャ

感想


本の中でもことわりが入っているけど、リポジトリパターンとかDDDだけの内容でないものもそこそこある。なんとなくモヤモヤは消えたものの、やはり実際に書かないとわからんので、1章から順番に読み直して順次なにかに適用していきたい。

その他


本の内容と関係ないけど、Kindle Paperwhiteで読むとソースコードのところが読み辛くてたまらなかった。