概念設計は予見できない変更をなくすのではなく局所化する

適切な概念設計であっても、将来の要求によって概念の追加や再構築が必要になる。 概念設計の効用は、未知の要求をすべて実装済みにすることではなく、既知の事実を異なる理由とタイミングで変わる概念に分け、変更の影響を狭く保つことにある。

Order と Fulfillment を分けたモデルに、履行後も注文内容を変更したいという要求が加わったとする。 この要求だけでは、既存の Order を上書きするのか、成立した注文への訂正や合意変更を記録するのか、未履行分への指示だけを変えるのかが決まらない。 後二者なら、OrderAmendment や FulfillmentInstruction のような第三の概念を加え、履行済みの事実を残す方が自然である。 このとき Order と Fulfillment の区別は壊れず、むしろ変更の意味を見分ける土台になる。

一方、業務上の Order が「顧客が当初合意した内容」ではなく「後から変更され続ける現在の契約状態」を意味すると判明したなら、Order の定義そのものを改める必要がある。 どの Fulfillment がどの版の合意を履行したかという関係も必要になり、概念体系の再構築になる。

したがって、将来の要求が既存概念に収まることは、概念設計の正しさの証明ではない。 概念モデルは現時点のドメイン理解に基づく仮説であり、新しい要求はその仮説を検査する反例候補になる。

https://zenn.dev/takeshi_teshima/articles/bae79b2f0f97be

#software-design #conceptual-modeling #domain-model