Vlad Khononov (著)
オライリージャパン (2024/7/20)

ドメイン駆動設計という言葉をよく聞くので、まずは読んでみようということで読んでみた。（「エリック・エヴァンスのドメイン駆動設計」が原点的定番のようだけど、そちらは少し難解で本書の方が分かりやすいとのことだったので、まずはこちらから。エリック・エヴァンスのもいずれ読む）

ドメイン駆動設計というのは具体的な技術的な手法のことだとイメージしていたけれども、それよりもドメイン（業務）をどう理解し、それをどう設計に結びつけるか。その理解がまず前提にある、という考え方のようで、前半は業務の捉え方にかなりのボリュームが割かれている。

この部分は組織設計について考える際にもおおいに参考になった。具体的な技術のパートは経験値不足からはっきりとは理解できなかったけれども、これまで学んできたことをどうコードに置き換えるかの解像度はそれなりに上がった気がする。

境界の決定がシステムの本質

アーキテクチャの選択はシステムの設計です。システムの設計は文脈の設計です。文脈の本質は境界です。境界の内側に何があり、境界の外側に何があるか。境界を超えて、どうつながり、何が移動するか。何を選択し、何をあきらめるか。境界は、何が外部であり、何が内部であるかを明らかにします。

Bredemeyer Consulting: What is Software Architecture

本書で引用されている上記の文章が本質を明確に語っている。

境界とつながり方を決定する。それが本質だ。

たとえば、コードを書く際のフォルダの構成で何を実現しようとしているかがかなり決まる。何を何をどう分けて、どのような構造を構築しようとしているか。このあたりをどう決めればいいかがあまりイメージできていなかったけれども、それがかなりクリアになった。

同様に組織においても、どのような部署やチーム、人員を配置するか、という構成で実現できることのかなりが決まる。

つまり、逆コンウェイ戦略のように、実現すべきことに対して、境界とつながりをどう定義して、どのような構成の組織・システムを組むかが重要になる。

このことを考える前に3つのサブドメインについて押さえておきたい。

3つのサブドメイン（業務領域）に分類する

また、事業活動を細分化したサブドメインを3つに分類する。

コアサブドメイン（中核の業務領域）

コアサブドメインは、競争力の源泉となる事業の中心的価値を生む部分で、複雜であることが前提。単純なものであれば、簡単に他者に真似され、もしくはAIなどの技術の変化により一般化され、容易に下記の一般サブドメイン化し、当然競争力を失う。コアサブドメインを最重要投資対象として定義し常に進化させる必要があるし、何をコアとして定めるかが生命線になる。

一般サブドメイン

なくてはならないが、競争力の源泉になるわけではない領域。ここに投資しても顧客が選ぶ理由になるわけではないので、標準的な解決策で十分。外部のソリューションを使うなど、外部化・標準化が吉。

補完サブドメイン

コアを支えるために必要であるが、外部のソリューションを使えるほど一般的ではないため自社固有のものが必要な領域。ただし、ここが直接利益を生むわけではないので仕組み化や自動化、もしくは一般サブドメインへの転換を計るなど、可能な限り簡単に済ませる。

業務を分類し、それをどう扱うべきかを明確に定義する。そして重要な部分に重点的に取り組む。その時重要なのがコアは複雜であれば複雜な程よく、変化可能なものであるべき（他者が真似できない複雜な課題をシンプルな形で顧客に提供できる）ということだ。

ここで境界とつながりの設計が必要になる。

境界とつながりを設計する

コアは複雜であれば複雜であれば良く変化可能であるべき。ただし、コアサブドメインだけでは業務全体は成立しないため、サブドメインどうしのつながりはどうしても必要になる。

ただし、複雜なものが複雜なまま接続すると、変化が生じた際に必ずバグを引き起こす。なので、接続部分はなるべく単純で変化の少ないものであるべき。つまり、コアはその内側だけで複雑さを扱えるように粒度と境界を選択しなければならない。

この接続が単純で最小限であることが疎結合だが、境界の設定をミスって、あるサブドメインと別のサブドメインが過度に関わらざるを得ない（密結合）状態になると、変化に従いやがて問題を引き起こすようになる。（一方が変化した際に、もう一方もそれに合わせて大きく変化する必要があれば、不整合が多発したり、カオス化して変化すること自体が困難になる）

複雑さを存分に扱うことができ、かつシンプルな接続を維持できる境界と接続方法を決定する、これがシステム設計の肝なんだろう。（これは、ここまでの読書でも繰り返し出てきたこと。チームトポロジーの意義がだんだん理解できるようになってきた。）

業務領域は「発見」であり、区切られた文脈は「設計」です。

本書 P.49

複雑さを扱うことが競争力の源泉になるが、それを実現するにはそれを可能とする構造の設計が必要なのだ。

そして、その知見がソフトウエア開発の領域にかなり蓄積されている。

ちなみに、こういう構造の理解が前提なら、ソフトウエア開発分野の組織はそれはもうすばらしい組織運営がされているんだろうと思ったけど、けっこう二局化するらしい。

人間のあつまりだと、余計な力関係や感情が働いたりと設計の障害があったり、簡単に人間の定義を変えたりリファクタリングしたりできないですもんね。複雑性を担っているのが個人であって構造化するのが困難というのもよくある話。

構造の設計なくしては、競争力を維持することはできないけれども、コードも組織も「巨大な泥団子」を解消するには地道な改善しかないのかもです。（ただし、この辺を言語化できる人が一定数いないと厳しいな）

あと、この辺の問題って自然界はどう扱っているんだろう。

認知負荷の制限はあまり関係なさそうなので、複雑なものが複雜なまま関係してそうだけど、自然界も変化することが前提だろうから何らかの仕組みがあるはず。コードと違って、パラメーターの直接的なやり取りというよりはもっとカップリングのような直接的ではない関係性なんだろうな。そして、そういう組織のありかたもたぶんあるんだろう。（おそらく前提が揃ってなければ機能しないと思うけれども）