業務の語彙と、システムの語彙をどこでバランスさせるか、ということを考えた

業務的に、例えば伝票一枚でも一つの業務の単位だし、伝票を束ねた一つの塊が経理担当の仕事の管理単位になるし、月一回全体で締めた束の束みたいな概念も有るし、決算で処理済みの過去分みたいなのも有って、同じ情報でも取り扱い単位はどんどん変遷していくんだけど…続く https://t.co/6XVrD4tYog

— magnoliak🍧 (@magnolia_k_) 2021年11月2日

そこに対してエンティティとか集約っていう割とシステムサイドから出発した語彙を当てはめようとすると、その情報の位置付けや意味が時系列とか工程とかで結構変わって行くのに紐付けづらさが有ったりしませんかっていうことをさっき考えた

構造の柔らかさに差が有るんだよね

— magnoliak🍧 (@magnolia_k_) 2021年11月2日

業務の語彙の階層的な構造に対応できるシステム側の語彙はまだ発明されていないというか、「とても硬いもの」に持って行こうとするんだよね、意識的に

— magnoliak🍧 (@magnolia_k_) 2021年11月2日

業務要件における情報って、大きな括りで見ていくと必ず階層的な構造になっていて、下位の情報が上位の情報の意味や位置付けを変えることも有るし、上位の情報が下位の情報に影響することもある。

また、一定期間を過ぎると、上位の情報の概念しか使われなくなることもあるし、情報システムの変化により過去の下位の情報がまた意味を持ち始めることもある。

モデリングという行為が、ボトムアップスタートだったにしろ、トップダウンスタートだったにしろ、上位の情報の価値と、下位の情報の価値に優劣は無く、常にその業務の取り扱いたいスコープによって大きく変わるけど、案外その影響が色々なところに漏れ出てしまう、というところを考えていかないといけないよね。

ってここまで書いてみて具体例が無いとわかりづらいと思った。