『データモデリングでドメインを駆動する』について学んだことの報告
# 開催内容
杉本啓(2024)『データモデリングでドメインを駆動する』技術評論社(以下、本書)を輪読会するということで勉強会を開く。
開催期間は、2024-11-07から2025-02-06であった。
第3回までは参加者は主催者1人のみであったため、輪読会という形式は諦めた。主催者が本書を読んで、要約をし、気になった点について話し、参加者がいた場合は質疑応答をする、という形式にした。
# 開催目的と結果
弊社matsuri technologies株式会社が開発、運用、保守をしているシステムはマルチプロダクトになっている。しかし、元はモノリシックに開発し、いわば業務フローを作り、それを効率にしていく、というものであった。それが分割されていった背後には本書で取り扱っている基幹系システムの考えや、分散/疎結合/非同期の考えがある。そして、今事業が大きくなっていき、新たな機能や新たな責務が多様な形で求められ、場合によっては基幹系システムと呼べるようなものが求められている状況において、改めてモノリシックからマルチプロダクトに移行した際の考えを振り返る必要性が出てきており、そして、本書で扱っているデータモデリングと設計について学ぶ必然性が出てきた。
残念ながら参加者はほとんどいなかったので、技術周りでは強いが、設計やデータモデリングでの強みがない弊開発部に学んでもらうことはできなかったが、notionにおいて要約資料の配布という形で記録の永続化をしたから、いずれ重要性と緊急性とが増してきた時に使えるツールの提供はできた。
個人的な成果としては、本書を通して、さまざまな知識を得られたということもあるが、何よりも、この勉強期間中に作ったシステムや今新たに作ろうとしているシステムにおいて、本書が扱っているSoAとSoMの分割とそれらの接点を設計に盛り込めたことや、可用性を前提とした設計をしたこと、そして、偶有的な複雑性ではなく本質的な、複雑な、解決領域においての問題に取り組めるようになったことである。
# ちょっとした要約
本書で扱う基幹系システム、その存在理由は、企業のさまざまな活動を指示・制御することである。
# 基幹系システムについて
基幹系システムの構成は以下の通りである。
- SOE(System of Engagement/Empowerment): 関わり合いのシステム、エンドユーザーを支援する
- OOUIを参照せよ
- SOR(System of Record): 記録のシステム、事業体を支援する
- SOA: 活動のシステム。これが扱うのは、2つ:
- 「残」を管理する「業務機能」
- 取引視点で残を横断する「業務プロセス」
- SOM: 経営管理のシステム。これが使うのは、
- 全社視点から業務機能別の管理にいたる階層構造
- SOAとSOMとが分離・統合しているが、SOAとSOMは別ではない。
- SOA: 活動のシステム。これが扱うのは、2つ:
SoAにおいて特に重要な、そして、基本とすべきものは、「残」である。そして、そのトランザクションである。残とはどのようなものか？
- 各観点から見た場合(p.66)
- 業務実行者の観点からは、
- 業務を駆動し
- 業務の完了基準を提供し
- 業務を非同期/疎結合に分割するもの(バッファ的)
- 業務と帳簿を設計する人に対しては、
- 業務分割の自然な切り口を提供し
- 業務と帳簿を一体として分割するとともに
- 業務責任の線引きを明確にする
- 業務実行者の観点からは、
- 必然的なものである(pp.71-72)
- 残管理のためのデータ項目は、業務のあり方を踏まえて、各項目の要否や別のデータ項目代替可否を検討し、決定されるものであるから。
- 残は責任であり、業務であり、帳簿である。(p.74)
- ゆえに、残に応じて、業務だけでなく、帳簿も、実践的なデザインに分割しなければならない。
残ではないものはSoAにはいれるべきではない。ビジネスルール、ビジネストリガー、ビジネスレポーティングといったものはSoMのものである。これらは変わりやすいものであり、変更しづらいSoAに入れるべきではない。また、マスターデータなどをSoAにいれることも、SoA同士が密結合することになり、よろしくない。
残ではないものは管理の考えであり、それはSoAと関連しなければならないが、その関連の仕方は非同期で良い。
SoMのやることは三層に分けられる。(pp.32-33)
- 上位：財務的な計画管理（資源配分）
- 会計報告と管理会計
- 中位：計画の策定と計画の展開
- 業務分野別の計画管理（調整的）
- 下位: SoAとSoMとが密接に結合しているが、別であり、現場活動と経営レベルの意思決定を密接につなぐ
このSoMの3層を理解し、SoAとSoMがどう連動するかを考えるべきである。
たとえば、トリガーというのがある。例えば、「在庫数が50以下になったら追加発注をする」というのがあったとしよう。この時、在庫管理システムと、発注管理システムはがそれぞれあったとする。この時、このトリガーはどこに置くべきか？ 在庫管理システムでも発注管理システムでもない。これらはSoAである。このようなトリガーは、SoMのものであり、SoAのどちらにおいても問題がある。どちらかに置いた場合、このトリガーの変更が生じた時に、ユーザーから見れば「なんで在庫/発注のためにこっちのシステムがメンテされなくちゃいけないんだよ」となる。そして、トリガーはSoAのライフサイクルとは別である。つまり、売れ行きが良くなったから、「在庫数が100以下になったら追加発注をする」とするなど、現場の仕事とは別のイベントで生じるものであり、現場のルールの変更よりも圧倒的に早いサイクルで変更されていくものである。このようなトリガーをSoAにおいてはならない。この場合、どうすればよいのか、というのはいくつか手法はあるが、例えばオブザーバーパターンを使うなどがありうる。
この基幹系システムに関するSoAとSoMの三層構造というのが、非同期、分散、疎結合のベースとなるものである。
このために、残をベースにした帳簿の分割と整合性、マスターをエンティティとロールで切り分けること、SoAは正確な原始データの提供をし、SoMはデータ加工をする、と責務を分けることなどが、設計として重要になってくる。
補足
システムというのはソフトウェアではない。
システムというのは、その語源通り、"σύστημα"(シュステーマ)、つまり、"σύν"(シュン)と"ἵστημι"(ヒステーミ)、共に、立つものである。複数の関連するコンポーネントがあり、それが相互作用し、1つかいくつかの目的や理念を持った共同体である。そのため、ソフトウェアがシステムになることもあれば、人の集団がシステムになることもなる。
そのため、SoMがソフトウェアという形態を取る必要性はない。あくまでも、ソフトウェアは管理過程の道具である。この道具性についてはOOUIでも指摘されていたように、UI/UXだけでなく、設計やアーキテクトにおいても同様に忘れるわべきではない。
# 求めるべきは仕様に関するミニマリズムである
システム設計において必要なのは、残をどうするかである。そして、その残に対処するために、可変性やミニマリズムが問われる。
- データモデル設計において重要なのは「残」である。(p.25)
- 可変性の採用の理由(p.185)
- 「要件がわからないから可変にしておこう、ではなく、可変にすることで得られる価値が明確にわかっているから可変にしよう」である
- そして、可変性は消していく(pp.188-190)
- ニーズや作業に関するではなく、求めるべきは仕様に関するミニマリズムである。(pp.177-178)
- 目の前のニーズにピッタリ寄り添い
- 必要とされる以上の余分な要素を排除する一方で
- 適用業務に対して過剰な縛りをかけることを避け
- ニーズが変化するというこれもまたリアルな認識を抱擁するソフトウェアモデル
# データモデリングにおける注意
データモデリングにおいて、ER図などに引きずられることがある。ここにおいて、図的記法は設計情報の表現の仕方、メタモデルは設計情報の整理の枠組み、という区分を忘れてはいけない。
そして、リレーショナルモデルがデータモデリングの基本にはなるが、リレーショナルデータは、一件ずつで意味が完結しないデータが苦手であるので万能ではない(pp.2633-269)ということを忘れてはならない。
次に、データモデル等価性から、データモデリングのテーマではないものを見ることが重要である。ナチュラルキーかサロゲートキーかというのはデータモデル等価であり、ユーザーの関心はナチュラルキーである。
このようなユーザーの関心と技術的関心の分離は、偶有的な複雑性への対処となりうる。偶有的な複雑性は、たまたま生じたもの。本質的な複雑さに立ち向かうために、偶有的な複雑さを取り除く、そのための道具の進歩と道具の理解がある。
データモデルにおいて、概念モデルについて取り上げられることもあるが、結局は、データ表現から独立したデータモデルという解釈がもっともまともであろう。(pp.312-320)
# 深いモデル
筆者はDDDに対して、共感しつつも批判している。そのベースとなるのは、問題領域と解決領域の区分である。
具体的な批判対象としては、(それはDDDを換骨奪胎している人たちがいることももしかしたら関係するかもしれないが)「コアドメイン」というドメインがコアかサブかで議論が生じるようなのでは問題領域と解決領域とを区別できていない。ドメイン層のモデルオブジェクトがドメインモデルと捉えられがちであり、本来はもっと広いことが見落とされていること。
そして、共感するものとしては、ドメインモデルが、ドメイン(問題領域)のではなく、ツール(解決領域)、問題を解くための道具に関する諸々の概念を含む領域にある(pp.337-338)。これをエヴァンスは「深いモデル」と言っている。 ドメインモデルというのは、ソフトウェア固有のものではない。伝統的・古典的ドメインモデルが存在するなら、それを意識の光のもとに晒し、批判・再構築をするべき(p.344)
ドメインモデルはドメインから生まれるのではない(p.349)。解決のための道具として作られるものである(p.342)。ユーザーの間主観的なメンタルモデルである(p.345)。
# まとめのまとめ
以上で見てきたように、基幹系システムの設計は、ビジネスとデジタル技術の第三の知識領域である。(pp.366-369)ドメイン、技術、設計に関する知識、そして何よりも謙虚さ、つまり、自己の知識の相対化と知らないことのちょうど良い扱い、経験に応じた理解と知識の更新をする能力が求められる。
アーキテクチャを扱うアーキテクト(設計士)として意識しなければならないのは、建築士と同様に、ストラクチャではなくアーキテクチャである。ストラクチャは何らかの対象に内在する構造、アーキテクチャは状況と構造を結びつける関係性のデザイン。(p.368)
このアーキテクチャは、ユーザーが置かれた状況を、情報システムとソフトウェアで変える際の「構え」である。ユーザーと話し、建築物がユーザーにとってどうあるべきかを描き出す。そして、道具を作る。SoAとSoMのアーキテクチャが全然違うのもそれによる。
# 終わりに
本書の初めに(p.v)では、「明日から現場で使える」テクニックを提供するものではなく、読了した読者の目に現場の景色が昨日と異なって映ることを願って書いたものである、と書いてある。
まず、テクニックはほとんど扱われていなかったので事実である。しかし、読了せずともページを進めるごとに景色が変わっていき毎日が新しく見えていた。そして、可変性を利用した設計や、ユーザーへの問いかけなど、その翌日から実際に行動が変わった。
このような点で、本書の目的は私には少なくとも達成したと見受けられる。
輪読会を当初想定していた形式で実現できなかったのは残念である。しかし、notionに輪読会のための要約、また本記事という要約の要約が残せたのはよかった。これらを見て、もし気になった方は、本書を取って自分で読んで、自分にとっての気づきを得てください。