なんとか月末に読み切りました。
所謂 DDD 本です。

ドメイン (業務やアプリのロジック) の複雑さを分離、再構築する事でなるべくシンプルなモデルにする方法を書いている本でした。
言葉にすると妙に簡単そうに聞こえるんですが、実際に例題を見つつ描かれる図を見ると、要求からどうやってその図に行き着くんだよ… みたいな状況です。純粋に設計力 (経験値) が足りないのですが、悔しいですね。

内容

かなり骨太な本で、難しい内容なので一回では理解しきれませんでした、はい。
まぁそんなので理解出来るなら設計で皆苦労しないので、これからことあるごとに読み返して、ブログで考察したいと思います。

この本を読んでいて思ったポイントはいくつかあります。

  • デザインパターン
  • UML
  • Java

この 3 点が DDD 本のなかで繰り返し出てきます。Java は実際のプログラムで説明する際に使用されているだけなので、OOP な言語のある程度の理解 (OOP 的にプログラムを書いている経験くらい) があれば問題無いと思います。

また、今回の読書で設計時に意識すべき所はレイヤ (階層) とモデルの分割でした。
レイヤは 4 つに分割されて説明されてました。

  • ユーザインターフェース (プレゼンテーション層)
    ユーザが直接触れる部分。
  • アプリケーション層
    アプリケーションの動作部分。しかし、このレイヤは薄く保ち、ビジネスロジックはドメイン層に委譲する。
  • ドメイン層 (モデル層)
    ビジネスの概念や状況、ルールを表す。それ以外は置かない。
  • インフラストラクチャ層
    上位のレイヤ (ユーザインターフェース、アプリケーション層、ドメイン層) を支える為の技術的機能の実装層。
    ベースとなるレイヤ。

レイヤを 5 つ以上に分けてしまうと逆に設計がおかしくなる為、
このレイヤの枠組みで適切に配置する事を考えると良いっぽいです。

モデルの分割に関しては、モデルを O/R マッピングで捉え、各モデルに適切なデータを持たせる事を考慮する必要がありました。
ドメインをベースにやり取りから何処にどの程度のデータを保持させるのかという観点でモデルの設計するので、システムを拡張、改変する度にモデルの再設計を行う必要があります。この辺りは、システムを人間関係や、仕事の部署のやりとりでイメージすると感じが掴めるのかなと思います。僕はそれでイメージしました。

特に関係図を職場として見た場合、債務が一極集中しているのは明らかに不健全なので、モデルの場合も同様である事が容易に想像出来ます。

まとめ

今回だけでは理解しきれなかったので、これからもちょくちょく読み返し、まとめる作業が必要という事が分かりました。特に、絵を描いてまとめる能力を養う必要があります。特に僕は手間をさぼる癖があるので、ちょくちょく絵を描いて設計する癖をつけるようにします。