MENU

『ドメイン駆動設計』第4章 エヴァンス本 まとめ&感想

DDD

前回のふりかえり

  • 第3章の主旨
    • モデル駆動設計では、分析と設計で同じモデルを使う
      • 分析と設計で別のモデルを使用すると、それぞれの作業で得られた洞察を反映できなくなる
    • モデルと設計(≒コード？)はお互いが対応してなければならず、一方と変更したら他方も変更しないといけに
      • それを実現させるのに、OOPは効果的

第2部 モデル駆動設計の構成要素

  • ドメイン駆動設計のプロセスを回復力のあるものにするには、モデル駆動設計がどのようなものに支えられているか理解する必要がある。
    • 4章、5章、6章では、モデル駆動設計の標準パターンについて説明する。
  • ナビゲーションマップが掲載されていましたが、しょぼちむさんのノートがめちゃくちゃわかりやすかったです。

syobochim.hatenablog.com

第4章 ドメインを隔離する

  • ドメインオブジェクトはシステムの他の機能から切り離す必要がある。
    • ドメインオブジェクトはDDDにおけるモデル要素である
    • 切り離しを行わなければドメインを容易に見失う(そのコードがドメインだと気づけない)

レイヤ化アーキテクチャ

  • コードをレイヤ化する設計方法。各レイヤは同じレイヤの他の要素か、下位のレイヤーにしか依存しない。
レイヤ名　　　 責務
ユーザーインターフェース層
(プレゼンテーション層)		 ユーザーに情報を表示し、ユーザーからのコマンドを解釈する
アプリケーション層 ドメインオブジェクトが問題を解決するようにサポートする、作業の調整役。このレイヤは薄く保たれる
(このレイヤ自身が何かの業務を行うことはない？)
ドメイン層
(モデル層)		 ビジネスソフトウェアの核心。ビジネスルールは全てここに集約される
インフラストラクチャ層 上位のレイヤを支える一般的な技術的機能を提供。
(データ永続化・メッセージ送信など)
  • モデル駆動設計はドメイン層を分離してはじめて可能になる。

モデル駆動設計を可能にするには、下記の点に留意する必要がある。

  1. 複雑なプログラムはレイヤに分割する
  2. 各レイヤで設計を進めて、凝集度を高めて下位層だけに依存する
  3. 上位のレイヤーに対しては疎結合にする
    • 依存関係を一方向だけにする
  4. ドメインモデルに関係するコードを1つの層に集中させ、他の層から分離する。
    • ドメイン層はモデルとモデルに関する設計が全て現れる場所
    • MDDではモデルの概念(設計)を映し出すドメイン層(実装)によってソフトウェアが構成される。
    • ドメインロジックがプログラムの他の関心事と混ざり合っていると、設計と実装を一致させることが難しくなる。

アーキテクチャフレームワーク

  • メール送信などの技術的な機能は、インフラストラクチャ層において サービス として提供されるのが一般的
    • 上位のレイヤーは「どのように」送信するか気にしなくてよくなる
  • (上位レイヤーから呼び出される)サービスとして作ることが難しい時に、アーキテクチャフレームワークが使われる
    • フレームワーク全てを利用すると、制約が強すぎるために開発の妨げになることがある。
    • それを避けるには、目的達成に必要な機能のみを適用する。実装とフレームワークの結合度を下げ、設計上の意思決定を柔軟に行えるようにできる。

利口なUI

[利点]

- 単純なアプリケーションの生産性が高い。すぐ作れる。
- 開発者の練度が高くなくても仕事になる。
- 変更による影響がその画面だけに留まるので、部分的な作り替えが楽。

[欠点]

- アプリケーションを統合することができない。データベースを介してつながっている状態。
- ふるまい(≒ビジネスロジック？)の再利用・抽象化ができない。
- アプリケーションはすぐ複雑になってしまい、成長させようとしても単純な機能追加しかできない。
  • 利口なUIで作成したシステムをMDDに方向転換するのは至難の業。MDDに取り組むつもりなら利口なUIは最初から回避しなければならない。

気になったこと・感想

  • 第1部から「モデルと設計を一致させる」「設計と実装を一致させる」という言葉が出てくるんだけど、モデル・設計・実装 に対応するものが何なのかよく理解できてない気がする...

ドメインモデルは概念の集合である。「ドメイン層」は、モデルと、モデルに直接関係する設計上のすべての要素が現れる場所である。ドメインロジックの設計と実装によって、ドメイン層が構成されるのだ。そして、モデル駆動設計においては、モデルの概念を映し出すドメイン層によって、ソフトウェアが構成される。ドメインロジックがプログラムの他の関心事と混ざり合っていたら、設計と実装をこのように一致させることは現実的ではない。ドメインの実装を隔離することは、ドメイン駆動設計の必要条件なのだ。

ここから読み取れそうな感じがしたけど読めば読むほど混乱してきました。

↑を読むとこんな感じですが...第一部からのつながりで捉えようとしているから混乱している？

参考