物流種別と商流種別をきちんと区別して設計していない問題について、もう少し深堀します。線（物流種別）で説明すると複雑になるので、なるべく、点（拠点）で説明を進めます。
私が知る限り、ある程度大規模な製造業の場合、９０％近い企業が「物流拠点が決まると、その拠点の在庫所有組織が決まる」という業務ルールを持っています。
従って、
在庫エンティティ：[物流拠点コード、品コード]-(在庫数)
業務ルールエンティティ：[物流拠点コード]-(在庫所有組織コード)
物流エンティティ：[物流番号]-(from物流拠点コード、to物流拠点コード、品コード、数)
となります。（本来、在庫エンティティのKEYはもう少し複雑ですが、単純化のために上記のようにします）
ここで、２つの業務進化を考えます。
１つ目は「グループ会社で物流拠点を統合するために、１拠点で複数の所有組織が発生する」という進化です。この場合、情報システムのデータの型が上記のように固まっていたとすれば、それまで物流拠点＝AとしていたものをA1とA2の２つに分けなければなりません。場所はA で同じであっても、A1の所有組織はa社、A2の所有組織はb社と区別できるからです。この区別は、コンピュータ上のダミー的扱いかもしれませんし、ほんとうに拠点内で在庫の山を分けるかもしれません。
２つ目は、物流と商流が非同期になるケースです。たとえば直送。
物流は「製造会社→小売店」(1)であるが、
商流は、「製造会社→販売会社」(2)「販売会社→小売店」(3)としたい場合です。
このとき、上記の物流エンティティを(1)(2)(3)の３つ発生させなければなりません。
ここで注意が必要なのは、「物流拠点が決まると、その拠点の在庫所有組織が決まる」という業務ルールがあったため、(1)(2)(3)すべてを物流として表現しているところです。本来であれば、商流だけを表現できると良いわけです。
物流と商流は非同期に進化することもあるわけで、これらの変化をどのように設計として考慮しておくか、、、、、そこが重要だと思うのです。
では、どう設計すべきか？すでにここまで日記を読み続けている方には答が見えているはずです。
