赤シャツエンジニア

赤シャツエンジニア

エリック・エヴァンスのドメイン駆動設計 3章輪読会に参加して

引き続き参加してきたので、備忘録を

ddd-community-jp.connpass.com

今回は学びもありましたが、共感のほうがおおかったので、事前に自分でまとめたことを文章化しておきます。

ドメインと実装両方の目的に使える単一モデルを要求すること

なぜ必要か?

ドメインと実装両方の目的に使える単一モデルを採用しない場合、ソフトウェア開発をすすめていくと以下のようなことが発生します。 - ある程度の活動の後の、分析活動や分析モデルは、設計モデルと一致しないため、ドメインの重要な概念であったとしても設計モデルに取り入れられない - ある程度の活動の後の、設計活動や設計モデルは、分析モデルと一致しないため、ドメインの重要な概念を失いながらモデリングされる

エヴァンスの言葉では以下のように書かれています

分析と設計の間に致命的な亀裂が生じるため、それぞれの作業で得られる洞察は互いに活かされることがないのだ(p46)

分析・設計モデルを互いに考慮しないということが、互いの活動で発見したドメインの重要な概念の欠損を起こし、ドメインとソフトウェア実装の乖離が大きくなります。 結果として、結果としてバージョンアップ・保守を行う際には、

ドメインを理解し、 ②実装を理解し、 ③ドメインと実装の変換を思案し、 ④ドメインと実装に不整合が起きないか?

ということを考慮して実装しなければならなくなります。また、副次的に以下の作業も発生します。

ドメイン分析の資料を作成し ②実装を図示し ③分析から実装に落とし込む変換内容を図示し ④既存機能の入念なテスト

ドメインと実装両方の目的に使える単一モデル」どのような活動か?

モデル駆動設計は、分析モデルと設計という二分法を捨て去り、両方の目的に使える単一のモデルを探し出す。...そのため、我々は選択したモデルに対する要求をもっと厳しくしなければならない。そのモデルは全く別々の2つの目標を満たす必要があるからだ。

ドメインを抽象化する方法は常に数多く存在し、アプリケーションの問題を解決できる設計も常に数多く存在する。だから、モデルと設計をむずびつけることは現実的に可能なのだ。

コードはモデルのひょうげんとなるから、コードに対する変更はモデルに対する変更になるかもしれない。実装を一分の狂いもなくモデルに結び付けるには、通常、オブジェクト指向プログラミングのようなモデリングパラダイムをサポートする、ソフトウェア開発のためのツール言語が必要である。
(p47)

イメージにすると以下のようになると考えました。

f:id:mametarou963:20200927111054j:plain

初期設計時の活動は以下のようになると考えました。 - 分析により生成するモデル群はたくさんある - 設計により生成されるモデル郡はたくさんある - 両方を満たすモデルは必ずある。両方を満たす一つのモデルを探索する - 探索したモデルを忠実にコードに落とす。モデルを忠実にコードに落とせるように、オブジェクト指向などのサポートがある言語を選択する

また、開発中・バージョンアップ・保守時の活動は以下のようになると考えました。

  • [実装時に得られた知見]モデルに影響を与えるようなコード修正が発生した場合(※typoとかじゃなくてってこと)、分析・設計モデルも同時に見直すこと
  • [再分析時に得られた知見]モデルに影響を与えるような分析知見が得られた場合、設計モデルとしても耐えうるモデルを再生成し、再度コードに忠実に落とし込む
  • [再設計時に得られた知見]モデルに影響を与えるような設計知見が得られた場合、分析モデルとしても耐えうるモデルを再生成し、再度コードに忠実に落とし込む

つまり、上記のイメージを維持したまま開発を勧めるということかなと考えました。 これらを行うことで、分析・設計・コードが単一モデルを参照できるようになります。 参照箇所が一か所であるということは、そのモデルが変化・表現できる範囲であれば、 コスト安で拡張・保守できるということになると思われます。

これらの活動達成のために何が必要か?

  • 分析、モデリング、設計、プログラミングは同じ人がやること
    • 分析、設計、プログラミングは各フェーズで共通のモデルに影響を与えうるフィードバックがある。これらを分断してしまうと、先のイメージ通りのモデルとコードが維持できない
  • モデルを忠実にコードに落とし込めるソフトウェアサポートがあること(オブジェクト指向

ドキュメントの削減とドメインの概念の維持の効能

いろいろな書籍に何をドキュメントとして残すか?という話が出てきますが、共通項としてはコードに表現されていないことかなと思います。

分析と設計が分断されたソフトウェアの場合は、以下のドキュメントが必要になります。

ドメイン分析のドキュメント ②分析と設計の紐づけのドキュメント

しかも、設計時に出てきた問題を分析に持ち込めない結果、文章として表現できなくなり、相互参照できなくなり最終的にメンテナンスされないところまでが見えます。つまり文章量は多くなり、メンテナンスはされないという残念な結果になりそうです。

一方、理想的に「ドメインと実装両方の目的に使える単一モデル」が選定されていて、「モデルが忠実にコードに落とされている」場合、ドキュメントは格段に少なくなると考えます。 具体的には、コード自体がモデルを表現しており、モデルが設計と分析の側面をきりとっていますので、極論を言えば、ドキュメントには「なぜ」該当ドメインをそのように分析して「モデル」を生成したかが残ってれば十分ということになるかなと思います。設計のモデルについては、分析モデルと共通項を探したということで説明がつくため省略できる可能性があるかなと思いました。