エリックエヴァンスのドメイン駆動設計を読んでいる(第2部 第7章)

DDDの実践例

この章では貨物輸送会社のためのソフトウェアを例に挙げてDDDの実践例を示している。

気になった箇所を抜粋して考えてみる。

ドメインを隔離する:アプリケーションの導入

アプリケーションクラスは調停役であり、調停役は自分で出した質問に対する答えを出してはいけない。 答えを出すのはドメイン層の仕事である。

これはレイヤーの責務に関する内容。アプリケーション層はUI層とドメイン層を結ぶ薄い層であるべきで、 アプリケーション層には脳みそを持たせないというような表現がうちの現場ではされています。

エンティティとバリューオブジェクとの区別

配送記録

配送記録は他の配送記録と区別されるのでエンティティである。しかし、配送記録には貨物と一対一の関係があり、 配送記録単体での一意性は持っていない。配送記録は貨物の一意性から借用することになる。

エンティティであってもルートではない場合はグローバルな一意性はいらないということの例だと思います。

位置

位置のような基本的なエンティティは多くの理由から多数のオブジェクトによって使用される可能性があるので出来るだけ責務を小さくしておいたほうが使いやすい。

集約の境界

独自の同一性を持つものはそれぞれが独自に集約を持ち、そのルートとなる必要がある。

リポジトリの選択

リポジトリを持ちうるエンティティはルートのみであるため、リポジトリ候補は５つにあらかじめ絞れる。

どのリポジトリを実装するかについてはアプリケーションの要求に立ち戻って考える必要がある。

ここはかなり重要で、あまり理解できていなかった頃はとりあえずルートエンティティに対しては無邪気にリポジトリを作ったら良いと考えていました。 しかしそれでは意味がなくて、どのように使われるのか？どのようなことがドメイン層に求められるのか？を考えながら設計をしていくと、リポジトリが不要なエンティティも少なからずあるということを頭に置いておきましょう。

2つのシステムを接続する

異なるシステムを自身のシステムに接続する場合、自身のプロジェクトで用いているユビキタス言語に支障をきたす恐れがある。 これを防ぎ、かつ接続元のシステムから自身のシステムで必要な要素だけを取り出せるようにする薄皮的な層を腐敗防止層と言い、14章で詳しく説明があるようだ。