ソフトウェアは、パッケージ、モジュール、サービス、担当チームなどの境界によって管理される。 しかし、業務上の人、物、活動、責任は、一つの排他的な階層に所属しているとは限らない。 一人の顧客は、営業には商談の当事者、請求には支払主体、支援部門には問い合わせを行う利用者として現れる。
これは、意味ある単位が複数の全体へ所属するセミラチスとして捉えられる。 ソフトウェアを一つの分類木に合わせると、あらゆる文脈が依存する巨大な共通モデルを作るか、ある文脈の見方をほかの文脈へ押しつけることになる。 きれいな階層を作れたことは、問題領域を正しく表現できたことを意味しない。
一方で、現実が重なっているからといって、コードの依存関係まで無制限に重ねれば変更が難しくなる。 境界は重なりを消すためではなく、特定の目的に必要な整合範囲と変更単位を作るために置く。 同じ対象に文脈ごとのモデルを認め、その間の関係をインターフェース、イベント、変換として明示すれば、複数所属と局所的な変更可能性を両立できる。
したがって、モジュール図や組織図のツリーは現実そのものではなく、特定の目的による投影である。 目的が変われば別の境界が現れ、複数の投影の間には重なりが残る。 要求の構造が設計を制約しても一意に導出しないのと同様に、境界は発見されるだけでなく、変更理由や運用上の必要に応じて設計され、修正される。
この見方では、よい境界とは外部から独立した部分ではない。 それ自体で認識できるまとまりを持ちながら複数の大きな全体へ参加する単位を、変更可能な形で表現したものである。
https://www.patternlanguage.com/archive/cityisnotatree.html
#software-architecture #domain-model #modularity #semilattice #christopher-alexander