前書き
業後に以下のDDDイベントに参加してきた。
その議事録とアウトプットとしてここに残す。
画像の上２つが自分が書いたものである。
ドメイン駆動設計概要とユビキタス言語
コンテキストマップとコアドメイン
全体像を俯瞰したコンテキストマップ→その上でのどこにモデリングコストかけるか策定。コアドメインの時間経過に伴う変化(動き)、境界の位置含めて。詳細での検証の上で演繹的に前提となるマクロな境界の位置を修正。
それに対して参加者の方から、
①コンテキストマップからのコアドメインの定義という順番(トップダウン寄り)
②コアドメイン先に定義してからのコンテキストマップ作成という順番(ボトムアップ寄り)
どちらなのか？
という良い質問があった。
どっちかというとコアドメインを最初に特定して、それを支える業務サービスとして他のドメインがあるため、わりとボトムアップ式にコンテキストマップ作成という話をした。
自分の中では①②は割合的に、2:8程度の感覚である。
でも実際には、折衷方式だよねーなんて話し合いをした。
ではそのコアドメインはどうやって見つけるのだろうか？
という議論になって以下のSWOT分析の話を出してみた。
3CとSWOT分析を使ったコアドメインの特定
そこで自分は3CフレームワークとSWOT分析を組み合わせた分析を行っています。
コアドメインの持っているビジネスケイパビリティは、
・競合にない
・市場から求められている
・自分たちの強みを発揮できる
これらをすべて満たした特性を持っていないといけない。
つまり上図の斜線部分に配置されるようなケイパビリティがコアドメインの能力(ケイパビリティ)を持っていると言える。
そのため、自分はそのコアドメインの発揮するケイパビリティを明らかにするため、
3Cのベン図とSWOTマトリクスにケイパビリティをプロットして、
対象領域がコアドメインなのか？否か？を考えるようにしている。
SWOTでいうとSにあり、かつOにあるようなものをコアドメインの候補として考えればいい。
強みであると売り出すからにはハックされないようにしなくてはいけない。
つまりその領域コアドメインの領域内のワークフローは複雑さがないと競合という外部環境にハックされてしまう。
同時に、仮にスタートアップなどのスピード感が素早い組織にハックされたことを想定して、どの組織も汎用的に【強みを素早く変更するケイパビリティ】が求められる。
変化するコアドメイン
一度定義したコアドメインも徐々に強みではなくなっていく。
市場の縮小や、競合から自社の強みへのハックという外部要因だけでなく、
組織内のモノやヒトの構成要素の変化という内部環境変化によって、
コアドメインは別の者へと変わっていく。
それはプロダクトライフサイクルを考えれば当然の話である。
永遠にコアドメインである可能性はこのご時世では圧倒的に低い。
戦術と戦略の違い
戦術と戦略は、戦略の方が１段階抽象的である。
戦略を満たすためのいくつかの具体的な業務プロセスのバリエーションを戦術レイヤーで考える。
しかしながら、これらは基準となる視座の高さがあってこそ初めて議論できるものである。
事業戦略というものは、全社戦略レベルと比較したら戦術になる。
全社的に見てどこの事業にもっとも投資をすべきなのか？
そのもっとも投資している事業がコア事業であり、その組織のコアコンピタンスそのものと言ってもいいかもしれない。
そして１段階ズームアップして、その各事業の中にコアドメインがあるわけである。
この全体的なマップがなくして、「どこにもっともモデリングコストをかけるべきか？」という意思決定は無理ゲーである。
イベントストーミング、イベントソーシング
１，２章は実践的と言ってもわりと基礎的なこと(※といっても重要)になっており、
本格的な実践内容は３章からの成瀬さんの担当されている章。
その中で以下のつの質問が参加者の方から出てきた。
イベントストーミングとユーザーストーリーマッピングの関係
ユーザーストーリーマッピングのモデル作成時には、
匠Methodで言うとこの【価値分析】の記述をさらに１段階詳細化した物語を意識している。
そしてこのユーザーストーリー自体には、システムの内部でどんなタイムスタンプが押されているのか？とかは一切出さない方がいい。
なんでかというと、このユーザーストーリーはあくまでも利用者目線での関心であるので、
システム内部の細かなイベントとかは関心の外である。
対して、イベントストーミングに出てくるイベント系のモデルは、システム内部の構造などに関心のある開発者目線のモデルとなっている。
つまりユーザーストーリーを実現するための手段が入ってくる。
よって、確かに両者は似ているが、システム内部が関心であるのか？
それともシステムが利用者へ返す表情にあたる【リードモデル】よりも外側である利用者体験の物語にしか関心がないのか？
その用途によって使い分けることになるが、関心は分離して考えられているべきである。
みたいなお話を回答した記憶がある。
イベントストーミングとイベントソーシングの関係性
BAでの概念モデリングをAA層にてイベントソーシングで相似形に実装することで、
乖離を無くし、悪い意味でのコンウェイ力学を予防。
イベントストーミングで定義した仮説モデルが、実際に仮説指標の許容範囲通りに挙動するのか？
を下位の実現層であるAA層などで検証する。
その際に検証がしやすくするために、イベントストーミングと同じ姿として実装する。
そうすることによって、修正箇所や影響範囲の特定をしやすくする。
仮にBA層で、「その仕様変更によってどこも影響ないっしょ」と油断していたとしても、
AA層が相似形になっていることによって、
すぐに「実はこんな業務領域が影響受けます！！」とすぐさまビジネスサイドにフィードバックができるのだ。
それだけでなく、BA層で考えた品質、
たとえばパフォーマンス要件などが想定よりもだいぶ遅いといった時にでも、
BA側のワークフローのモデルとしてのイベントストーミング図と乖離なく、
そのまま相似形に実装されていることで、どこの層に問題があったのか？の特定などもしやすくなるし、同時に早めようとすることによってどの部分が影響を受けてしまうのか？の実験検証も非常にしやすいのだ。
なぜモデルとコードの乖離があってはならないのか
これはイベントストーミングによるモデリングに限らず、
他のモデリングだとしても、モデル図とコードの乖離はわざわざコンウェイ力学を悪い意味で受けに行くようなもんなので、基本的に自分たちの作成したモデルとコードの乖離はあってはならない。
超過激かもしれないが、減給対象としてしまうくらいの評価制度文化の方がいいかもしれない。
モデルと実装の乖離を無くそうというDDDのスタンスでは、
仕様変更やリファクタリングによってコードを変えた際、モデルもそれに伴って変更しなくてはならない。
ではそれはなんでなのか？
このメカニズム鋭い人やわたしが極めてきたビジネス書を知ってる人ならお気づきであると思います。
そうです！！演繹法の関係性です。
演繹法の簡単な説明
演繹法では帰納法などによって与えられた既存の前提となる一般論に当てはめて
その後の個々の事象の結果を予測するのに使う仮説推論技術です。
そしてもしも実験の結果である事実がその仮説と異なれば、当てはめた前提がそもそも違ったという気付きを得られます。 そしてボトムアップ式に前提を更新します。
モデルとコードで言えば、モデルが前提の一般論に当たり、コードが実際に動く具体な事象になります。
これと同様にして、コードの姿が変われば当然さっきまでの前提になっているモデルを同時に更新しなくてはいけませんよね？
でないと、前提条件と個々の事実に当たるコードが乖離しているんだから。
それが結果的に、「この業務ってなんのためにあんだっけ？」みたいな不透明さを生み始めたりします。