思考と現場の間で

「いいサービスづくり」のために、組織づくりやソフトウェア設計など、考えていることを書きます

【DDDメモ】モデルの整合性を維持する:腐敗防止層

腐敗防止層

エリック・エヴァンスドメイン駆動設計 P.374

 外部システムとのインタフェースには多くの渉外がある。例えば、インフラストラクチャ層は、プラットフォームが異なっていたり、異なるプロトコルを使用していたりするかもしれない他システムとの通信手段を提供しなければならないのだ。他のシステムのデータ型は、新しいシステムのデータ型に変換しなければならない。見過ごされがちなのは、他のシステムが同じ概念ドメインモデルを使用していないという可能性である。

【中略】

低レベルのインタフェースを使うと、他システムのモデルの持っている、データを説明し、その値と関係性を制約する力が奪われてしまう。また一方で新しいシステムに対しては、自分のモデルの言葉にないプリミティブなデータを解釈するという負担を課すことになる。
 必要なのは、別のモデルと接している部品の間で変換できるようにすることにより、異質なモデルの要素を消化しきれずにモデルが崩壊しないようにすることである。
 それゆえ:
 隔離するためのレイヤを作成することによって、クライアントに対して、独自のドメインモデルの用語で表現された機能を提供すること。この双は、既存のインタフェースを通して他のシステムと通信するので、他のシステムを修正する必要はほとんどないか、全くないこともある。内部的には、このレイヤが必要に応じて、2つのモデル間での変換を両方向に対して行う。

 すでにあるシステムを新しくする場合、一気に全てを捨てて新しくできることはそう無い。現状のシステムを残しつつ新しくしていくという形が多いのではないか。そういう意味で、腐敗防止層を設けてインタフェースを明確に定義するというのは有効。古いシステムになると、そのインタフェースもドキュメントが陳腐化していたり、知っている人がいなかったり、使ったり変更するのが難しくなる。そういう意味でも、仕様をもう一度洗い出し、定義し直すというのは意義があるものだと思う。

エリック・エヴァンスドメイン駆動設計 P.379

 どんな統合にも、オーバーヘッドはつきものである。単一の境界づけられたコンテキスト内で徹底して継続的な統合を行う場合から、共有カーネルや顧客/供給者開発者チームといった、それほど深く関わりの合わないものを経て、一方通行の順応者や腐敗防止層といった防御的な態度に至るまで、オーバーヘッドは存在する。統合は非常に有益かもしれないが、必ず高く付くのだ。それが本当に必要かは、確かめなければならない…。

 設計としてはあるべき姿があるが、オーバーヘッドやコストがかかるという事実がある。その点に関しては気をつける必要が有る。作っただけで何も効果がないどころか、余計に手間とコストがかかるようでは、そもそも何のためにやるのかがわからなくなってしまう…。