去年の夏前くらいにDDDまわりの勉強していた。でこのメモを書いていたので少し直して晒してみる。 前回の続編。

DDDの戦略的設計で出てきた話を少し列挙する。

抽象化の方法(蒸留)

コンテキストマップを用いてドメインやコンテキストの関係を発見し、概念に一貫性をもたらした開発をしていたとしても維持したり改善したりは難しい。

そのためのアプローチについてDDD本では言及していた。コーディングにとってのリファクタリングみたいなものだけど、より観念的だった。

優先順位

コアドメイン

一番ビジネスに重要なドメインの改善を選ぶ。

汎用サブドメイン

ビジネス上の差別要因にならない汎用的な機能が必要になる。しかしそこに優秀な人材をあてたり、開発コストを投入しすぎたりしないようにする。

文書化

声明文

ドメインの説明と、ドメインがビジネスにもたらす価値を書いたもの。

ハイライト

ドメインの中心的な構成要素が何であるかを理解させるように書いたもの。 よくアーキテクチャとかインターナル・アーキテクチャとかの項目にあたる。

改善方法

書かれてることを並べるとこんな感じになるけど。インタフェースとか抽象化を重ねていって読みにくさがますなぁ 思った。

もちろんドメインに関する改善であってコードは別ではあるのだけれど結局は対応させるはずで、そうするとインタフェースなりプロトコルなりで実装を隠蔽する方向にすすむ。

パターン名	メモ
凝集されたメカニズム	概念的に関連のある処理をドメイン内の小さいフレームワークとして作り直す
中核の隔離	重要度が低い概念は汎用サブドメインに切り出してコアドメインを小さく保つ
中核の抽象化	モジュール間に相互依存がある場合に関係を切り出してインタフェースにして中核のモデルとして独立させる

大規模な構造

DDD本では大規模な構造を全体像を理解しやすくするためにコンテキストマップに与えられる解釈や説明だとしていた。 言い換えると、コンテキスト間の典型パターンの名前や名前を与える方法だ。 DDD本の著者も未完成としていたし、実際に足りないしわかりにくいと思った。

パターン名	説明
メタファー	わかりやすい具体的な概念に例える
責務の階層	レイヤーアーキテクチャのように概念間に階層を見出して説明する
知識レベル	他のオブジェクトグループが利用するストラテジーを集める

感想

大規模なモデリングに対するアプローチなので当然なんだけど、抽象化をたくさん挟んでいき中核ドメインを小さく保とうとするテクニックが多い。 中核ドメインを小さくするとプラグインや多態を利用することになり読みやすさは減る。 ここにあるアプローチは必要に駆られるまで避けないと辛くなるなぁと思った。

ドメインは責任が明確な単位。使われるユビキタス言語に注目すると同音異義語がなく複数の意味を保つ用語がない。 コンテキストは実装なのでドメインとずれることがあるが揃えるようにリファクタしていくべき。