Eric Evans氏はDDDが完璧主義者のためのものではないと述べた

ドメイン駆動設計(DDD)の当初からの問題は完璧な設計を求める探求行為であるが、DDDは完璧主義者のものではない。この探求を止めるために、完璧ではないがよく設計されたソフトウェアの開発方法に関する発想を得ることが必要である。Eric Evans氏はアムステルダムで開催された最近のDDD Europe Conferenceにおける発表で、DDDに関する経験からいくつかの例を提示した。

Evans氏は最初のDDDの著者であり、もともとの境界付けられたコンテキストの目的は、行為を阻害するチームと同様に、自分たちが開発するソフトウェアが置かれた環境が多くのレガシーや他の外部システムと乱雑に混ざっていることを認識することであったと述べた。このコンテキストは、概念的に一貫し、特定の単語が常に同じ物事を意味するソフトウェアの部分の周囲を取り巻く。開発者として、コンテキストの境界の内部にいるかどうかを判断し、そのコンテキスト特有のルールに従う必要がある。この境界にはそこに適用されるルールを定義する自由が与えられる、単に使用される単語だけでなく、アーキテクチャと開発プロセスもである。Evans氏は自律すべきマイクロサービスは良い境界付けられたコンテキストであるが、これは開発者が時々解釈するような、常にサービスが境界付けられたコンテキストであるということを意味してはいないと強調した。

Evans氏によるとコンウェイの法則と境界付けられたコンテキストの間には関連があり、この法則に支援されるように物事を準備するように進めるのが理想である。彼は2つのコンテキストを持ったシステムを例として挙げた。１つ目はクレジットカードに対する責務を持ち、もう１つは現金口座に対するものである。ここで組織構造、サブドメイン、そして境界付けられたコンテキストの間で調整する。しかし、市場セグメントのために事業の構造を見直し、ビジネス用の口座を個人口座と分け、各々の種別の口座に対してチームを再編成することになったとしよう。この２つのコンテキストはそのままであるため、各チームは両方のコンテキスト内で開発を行うことになり、時々各々の領分に触れる、つまりもう１つのチームと業務を調整する必要がある。Evans氏はこれを、ある速度になるためには調整が必要不可欠な二人三脚と比較した。ここでのリスクは巨大な泥団子を開発してしまうことであり、ソフトウェアに対する明確な管理が行われていないことがEvans氏が遭遇した良くある理由である。解決方法はおそらく腐敗防止層を利用して新しいコンテキストを作成することである。

時々モデルは多少完成せず、対処しようとした全ての事象を扱う能力に欠けることがある。都合が悪いように思えるが、より多くの事象に対処できるモデルを作成する代わりに、モデルでは扱えない事象に対応する関数を作成することが代替案となる場合がある。このような関数は多数のif-then-else文を利用し、別のモデルを作成することを回避するためにどんな高レベルの概念からも遠ざけられる。漏れや混乱を招く抽象化は決して用いるべきではない。Evans氏は、美しいモデルを持った手品のような機構を作成する代わりに、if-then-elseを用いるのが望ましいと述べた。このようなモデルは実際に動作するモデルを発見することさえも妨害してしまう。彼はこれが素晴らしいトレードオフに関する例であり、完璧な設計ではないが良い設計であることを目的とするものであると信じている。

Evans氏はモデルが完璧になるまで作業をすること、つまりそれまでソフトウェアの出荷をしないという行為を推奨していない。私たちは、設計とは最初に余分な時間を投資しその見返りを長期に渡り受けるという考えを克服しなければならない。しかし、極度に逆の考えに至る、つまり何かひどいハックをして出荷するという行為に走ってもならない。モデルに関するトレードオフを意識し、現在のモデルに完全に満足していないときに実行すべき手法を持っている場合にとても良い結果を得られるのである。