Domain-Driven Design(DDD) を最初に拾い読みしたとき、いちばん興味を持ったのは、第IV部 Strategic Design だった。
ある程度の規模のプロジェクトになると、DDD の「基本のモデリング要素(第II部)」と「ドメインモデルのリファクタリング(第III部)」だけでは、解決できない、扱いにくい問題が山積みになる。
・広大な開発範囲(壁いっぱいに広げても描ききれないクラス図)
・サブシステム分割と統合作業
・複数チームの役割分担
・既存のレガシーシステムとの連携
・他の企業のシステムとの連携
...
これに、開発の契約、出身母体の違うメンバーをかき集めた混成チーム、顧客の部門間の調整、別企業との事業提携の交渉、...。
さまざまな要素が、問題をさらに複雑にする。
開発メンバーの一人として参加するなら、まあ、こういう問題は、実感がわかないかもしれない。
でも、アーキテクトとか、プロジェクトの責任者、開発チームのリーダーとかになれば、こういう、面倒くさい問題の、直接の利害関係者になる。
自分たちではコントロールできない問題領域のはずが、「開発サイドで、なんとかしてくれ」となってしまうことも多い。
こういうのは、「調整スキル」とか「交渉スキル」という、いわゆる「ビジネススキル」の問題として取り組む方法はある。
まあ、そういうスキルは必要だし、役に立つシーンもあるけど、技術者たるもの、こういう問題も「設計」の問題として取り組みたい。
DDD の第IV部「大きな設計」(Strategic Design) は、まさに、こういう「設計」の考え方、やり方を扱っています。
エバンスの信念は、こういうスコープが広く、複雑な問題にも「ドメイン駆動」で立ち向かうこと。
ドメインを深く理解することが、こういう問題を解決する、確実で、効果がある方法なんだ、ということですね。
・ドメインの基本の枠組み、基本の軸を理解する
・ドメインに登場する利害関係者の価値観・行動原理を理解する
こういうドメインの理解にもとづいて
・サブシステムへの分割設計
・複数チームの役割分担や協力体制の構築
・既存システムとの連携インタフェースの基本設計
・他企業のシステムとの通信インタフェースの基本設計
をやることで、問題に適切に立ち向かかうことができる。
ドメインを誤解したまま、システム内部の技術的な視点と知見だけで、こういう課題に取り組むと、問題を悪化させる一方。
エバンスは、この点も、一貫している。
大きな戦略的な設計であっても、それは実際のコード「動くソフトウェア」と密接に関係づけなければ、意味がない。
上流専門のコンサルタントが残す、きれいだけど実際は役に立たない絵を描いてもだめ。
モデリング、設計の意思決定は、必ず「実装」して「コード」として表現すべきだし、動くソフトウェアこそ、設計のよしあしを教えてくれる道しるべ。
第IV部は、「大きく」「複雑」な問題がテーマだけど、設計の考え方や、パターンは、こういう「コードで動かす」哲学を貫いている。
私が、ドメイン駆動設計を重視する大きな理由が、この「実際に動くコード」を大切にするエバンスの発想・考えかたに強く、共感しているから。
モデリングは、コードに直接、結び付くものだし、そうじゃなきゃいけない。
「現場主義」も DDD の特徴のひとつ。
現場の開発者にとって、わかりやすいこと、やりやすいことに、とても価値を置いている。
もちろん、利用者やプロジェクトのオーナーの期待にこたえるソフトウェアを造ることが一番たいせつな目的。だからこそ、ドメインを理解する「ドメイン駆動設計」なんですね。
それと同時に、「ドメイン駆動設計」は、開発者にとって、
・わかりやすいコード
・扱いやすいコード
・取り組みやすいやり方
にも、大きな価値があることに、強い信念を持っている。
ドメインも実装技術も、両方を大切にする。両方の専門家が集まって、同じ言葉(ユビキタス言語)を使いながらいっしょに活動することで、大きな相乗効果が生まれる。
これが「ドメイン駆動設計」に一貫して流れるエバンスの考え方ですね。
ほんとうに共感します。
全体像を分析して、最初に大きな構造設計をしちゃって、その構造を固定する。
この up-front (前払い) 方式が、うまくいかないのは、現場でだれもが経験しているはず。
実際にやってみてわかること。新たにわかったことをベースに意思決定すべきテーマが多いこと。
大きな問題とか、システム間連携も、継続的に、段階的に、改良し発展させていくことが大切、という価値観ですね。
「大きな設計」も、足元の現実的で実践的な取り組みから始めて、「継続的に改良・発展」させていくべし、という価値観・信念が一貫している。
第IV部の三つのキーワード。
・文脈(Context)
・蒸留(Distillation)
・構造(Large-Scale Structure)
第14章は、広い開発範囲や、関連システムとの連携で、「大きなモデルの整合性、一貫性を維持する」ための考え方とやり方を書いている。
そのキーワードが「文脈(Context)」。
はっきりいって、わかりにくい言葉。
DDD を最初に読んだときは、ぜんぜんぴんとこなかった。
一方、この章の、サブシステム同士や、システム間の連携のやり方の7つのパターンは、具体的で、とても面白かった。
私が、DDDを「こりゃ面白い、使える」と最初に思ったのは、このシステム間連携の7つのパターンを読んだとき。(そういう課題にちょうど取り組んでいた)
一体化した統合システムとか、標準プロトコル、みたいなきれいな絵もあるけど、エバンスは「実践的には」それが、唯一の解ではないし、最善でもない、という論点。
"Separate Way(別の道)"パターンの説明には、はっとさせられた。
「ほんとうに統合や連携に取り組むことが正解か?」という問いを真正面から、発している。「統合」とか「標準インタフェース」とかは、エレガントな解に見えるけど、デメリットや実現課題も多い。
・「別の道」が、最善という場合も、多いんじゃないの?
・少なくとも、選択肢の一つとして、真剣に検討すべき。
実際に、連携課題を見直して、当面「別の道」を選択して、プロジェクトの状況改善に役に立ったことが何回かあります。
問題の先送り、というよりは、「本来のアプローチ」ではない、という判断ができたから。
そもそも、連携相手のシステムが、ドメインの構造を完全に間違えて実装している。ゆがみきったモデルに合わせるための開発作業は、あまりにも、後ろ向き。費用対効果が悪すぎる。
今、作っているシステムは、ドメインのモデルをうまく表現できるようになってきているので、こちらを完成させて、こちらを拡張していくほうが、費用も少なく、期間を短くできそうなことを、ほぼ確信できたから。
この15章は、「選択」と「集中」のやり方ですね。
中でも「コアドメイン」パターンは、ほんとうに目からうろこでした。
この本を最初に読んだのは、破綻したプロジェクトの建て直しの現場責任者として格闘していたとき。
・問題点をあげたらきりがない
・やるべきことが山ほどある
・もちろん、人手も時間も足りない
...
このときに「ドメインの中核」を見つけ、そこに資源を集中することを決意したのは、このDDDの15章、特に "core domain" パターンが大きく影響している。
きれいな総論としての「選択と集中」ではない。
もっと、泥臭い、開発の現場の実情を踏まえたエバンスの説明が、新鮮だったし、すっと体に入ってきた。
もちろん「コアドメインに集中する」と決めたからといって、すべてが一挙に解決したわけではない。
でも、そういう、しっかりした軸を持てたことは本当に大きかった。
私自身、いろいろ利害関係者、そして何よりも、現場で戦ってくれている、仲間たちが、進むべき方向を共有できたことで、明らかにプロジェクトの状況が改善した。
16章は、大きなドメインモデルの構造設計の話。
単純にいえば、ドメインモデルの内部も「レイヤーアーキテクチャ」が有効だよ、ということ。
いろいろなドメインオブジェクトを複数のレイヤに分けて、
・役割や意図を明確にする
・できるだけレイヤ間を疎結合にする
こうすることで、モデルがわかりやすく、扱いやすくなるよ、という話。
ファウラーの「アナリシスパターン」や Hruby の「ビジネスパターン」にもでてくる「全体の構造」をわかりやすくする時の、基本パターンですね。
ドメインオブジェクトのレイヤ構造の考え方は、小さなモデルでも重要だし効果的だと思っている。
ここらへんは、別の記事で、具体的に取り上げようと思っている。
来年もしばらくは、頭の整理や充電にあてる時間がとれそう。いいんだか、わるいんだか。
ここにきて、いくつかのクライアントに出向いて、現場で、基本的な設計や、プロジェクトの進め方をアドバイスすることが続いた。
格安というか、ほとんど無償のコンサルティングですね。
いままでとは違った会社やドメインに接することは、発見や刺激があって面白いことは面白い。
スポットで、少ない情報を元に、出たとこ勝負のアドバイスも、ある意味、腕の見せ所だとは思っている。
そうはいっても、気の利いた、気心の知れたメンバーで、小さなチームを組んで、じっくりと、ひとつのシステムを仕上げることに専念したい気持ちも、もちろんある。
あるいは、未知のメンバーと、新チーム結成、とかも、刺激がありそうだなあ。
隔週で、ドメイン駆動設計の勉強会を開いて、このブログに、まじめにいろいろ書くようになった。
その中で、知り合った人たちとの交流は、ほんとうにいろいろな発見と刺激があった。
勉強会は来年もぜひ続けようと思う。
ブログも状況が許す限り、がんばってみよう。
来年は、仕事のほうは、どうなるのかな。
そういえば、ここ数年、営業して仕事をとったことがないなあ。
基本、
・来るもの拒まず
・なんでもご相談に応じます
てな感じで、なんとかやってこれた。
来年もこんな調子で、いつものごとく、ある日、突然、火を吹いたプロジェクトとか、短期決戦の案件が飛び込んできて、「なんとかしてくれ」「なんとかしましょう」モードになっちゃいそうな気もする。
「ドメイン駆動設計」にこだわるようになってから、どんな案件、相談も、なんか、同じ考え方、やり方で、それなりに、いけそうな気がしている。
「ドメイン駆動設計」が、未経験な領域とかでも通用するのか、効果があるのか、新しい案件で、トライアルしてみたい、というのが今の素直な気持ちかな。
それでお金がついてくれば、いうことないけど、まあ、今までと同じように、割りの合わない仕事を、「面白そう」と言うだけで、やっちゃうんだろうなあ。
今の私に必要なのは、気の利いた技術者仲間ではなく、そろばん勘定がしっかりした番頭さんなのかな。
でも、やっぱり、設計をみんなでわいわい、がやがや、やるのが、一番ですけどね。
現実の問題は大きく、複雑
ある程度の規模のプロジェクトになると、DDD の「基本のモデリング要素(第II部)」と「ドメインモデルのリファクタリング(第III部)」だけでは、解決できない、扱いにくい問題が山積みになる。
・広大な開発範囲(壁いっぱいに広げても描ききれないクラス図)
・サブシステム分割と統合作業
・複数チームの役割分担
・既存のレガシーシステムとの連携
・他の企業のシステムとの連携
...
これに、開発の契約、出身母体の違うメンバーをかき集めた混成チーム、顧客の部門間の調整、別企業との事業提携の交渉、...。
さまざまな要素が、問題をさらに複雑にする。
開発メンバーの一人として参加するなら、まあ、こういう問題は、実感がわかないかもしれない。
でも、アーキテクトとか、プロジェクトの責任者、開発チームのリーダーとかになれば、こういう、面倒くさい問題の、直接の利害関係者になる。
自分たちではコントロールできない問題領域のはずが、「開発サイドで、なんとかしてくれ」となってしまうことも多い。
こういうのは、「調整スキル」とか「交渉スキル」という、いわゆる「ビジネススキル」の問題として取り組む方法はある。
まあ、そういうスキルは必要だし、役に立つシーンもあるけど、技術者たるもの、こういう問題も「設計」の問題として取り組みたい。
DDD の第IV部「大きな設計」(Strategic Design) は、まさに、こういう「設計」の考え方、やり方を扱っています。
解決の糸口は、やっぱり「ドメインの理解」
エバンスの信念は、こういうスコープが広く、複雑な問題にも「ドメイン駆動」で立ち向かうこと。
ドメインを深く理解することが、こういう問題を解決する、確実で、効果がある方法なんだ、ということですね。
・ドメインの基本の枠組み、基本の軸を理解する
・ドメインに登場する利害関係者の価値観・行動原理を理解する
こういうドメインの理解にもとづいて
・サブシステムへの分割設計
・複数チームの役割分担や協力体制の構築
・既存システムとの連携インタフェースの基本設計
・他企業のシステムとの通信インタフェースの基本設計
をやることで、問題に適切に立ち向かかうことができる。
ドメインを誤解したまま、システム内部の技術的な視点と知見だけで、こういう課題に取り組むと、問題を悪化させる一方。
きれいな絵だけでは役に立たない
エバンスは、この点も、一貫している。
大きな戦略的な設計であっても、それは実際のコード「動くソフトウェア」と密接に関係づけなければ、意味がない。
上流専門のコンサルタントが残す、きれいだけど実際は役に立たない絵を描いてもだめ。
モデリング、設計の意思決定は、必ず「実装」して「コード」として表現すべきだし、動くソフトウェアこそ、設計のよしあしを教えてくれる道しるべ。
第IV部は、「大きく」「複雑」な問題がテーマだけど、設計の考え方や、パターンは、こういう「コードで動かす」哲学を貫いている。
私が、ドメイン駆動設計を重視する大きな理由が、この「実際に動くコード」を大切にするエバンスの発想・考えかたに強く、共感しているから。
モデリングは、コードに直接、結び付くものだし、そうじゃなきゃいけない。
開発の主役は技術者
「現場主義」も DDD の特徴のひとつ。
現場の開発者にとって、わかりやすいこと、やりやすいことに、とても価値を置いている。
もちろん、利用者やプロジェクトのオーナーの期待にこたえるソフトウェアを造ることが一番たいせつな目的。だからこそ、ドメインを理解する「ドメイン駆動設計」なんですね。
それと同時に、「ドメイン駆動設計」は、開発者にとって、
・わかりやすいコード
・扱いやすいコード
・取り組みやすいやり方
にも、大きな価値があることに、強い信念を持っている。
ドメインも実装技術も、両方を大切にする。両方の専門家が集まって、同じ言葉(ユビキタス言語)を使いながらいっしょに活動することで、大きな相乗効果が生まれる。
これが「ドメイン駆動設計」に一貫して流れるエバンスの考え方ですね。
ほんとうに共感します。
継続的に発展させていく
全体像を分析して、最初に大きな構造設計をしちゃって、その構造を固定する。
この up-front (前払い) 方式が、うまくいかないのは、現場でだれもが経験しているはず。
実際にやってみてわかること。新たにわかったことをベースに意思決定すべきテーマが多いこと。
大きな問題とか、システム間連携も、継続的に、段階的に、改良し発展させていくことが大切、という価値観ですね。
「大きな設計」も、足元の現実的で実践的な取り組みから始めて、「継続的に改良・発展」させていくべし、という価値観・信念が一貫している。
第IV部のキーワード
第IV部の三つのキーワード。
・文脈(Context)
・蒸留(Distillation)
・構造(Large-Scale Structure)
文脈(Context)
第14章は、広い開発範囲や、関連システムとの連携で、「大きなモデルの整合性、一貫性を維持する」ための考え方とやり方を書いている。
そのキーワードが「文脈(Context)」。
はっきりいって、わかりにくい言葉。
DDD を最初に読んだときは、ぜんぜんぴんとこなかった。
一方、この章の、サブシステム同士や、システム間の連携のやり方の7つのパターンは、具体的で、とても面白かった。
私が、DDDを「こりゃ面白い、使える」と最初に思ったのは、このシステム間連携の7つのパターンを読んだとき。(そういう課題にちょうど取り組んでいた)
一体化した統合システムとか、標準プロトコル、みたいなきれいな絵もあるけど、エバンスは「実践的には」それが、唯一の解ではないし、最善でもない、という論点。
"Separate Way(別の道)"パターンの説明には、はっとさせられた。
「ほんとうに統合や連携に取り組むことが正解か?」という問いを真正面から、発している。「統合」とか「標準インタフェース」とかは、エレガントな解に見えるけど、デメリットや実現課題も多い。
・「別の道」が、最善という場合も、多いんじゃないの?
・少なくとも、選択肢の一つとして、真剣に検討すべき。
実際に、連携課題を見直して、当面「別の道」を選択して、プロジェクトの状況改善に役に立ったことが何回かあります。
問題の先送り、というよりは、「本来のアプローチ」ではない、という判断ができたから。
そもそも、連携相手のシステムが、ドメインの構造を完全に間違えて実装している。ゆがみきったモデルに合わせるための開発作業は、あまりにも、後ろ向き。費用対効果が悪すぎる。
今、作っているシステムは、ドメインのモデルをうまく表現できるようになってきているので、こちらを完成させて、こちらを拡張していくほうが、費用も少なく、期間を短くできそうなことを、ほぼ確信できたから。
蒸留(distillation)
この15章は、「選択」と「集中」のやり方ですね。
中でも「コアドメイン」パターンは、ほんとうに目からうろこでした。
この本を最初に読んだのは、破綻したプロジェクトの建て直しの現場責任者として格闘していたとき。
・問題点をあげたらきりがない
・やるべきことが山ほどある
・もちろん、人手も時間も足りない
...
このときに「ドメインの中核」を見つけ、そこに資源を集中することを決意したのは、このDDDの15章、特に "core domain" パターンが大きく影響している。
きれいな総論としての「選択と集中」ではない。
もっと、泥臭い、開発の現場の実情を踏まえたエバンスの説明が、新鮮だったし、すっと体に入ってきた。
もちろん「コアドメインに集中する」と決めたからといって、すべてが一挙に解決したわけではない。
でも、そういう、しっかりした軸を持てたことは本当に大きかった。
私自身、いろいろ利害関係者、そして何よりも、現場で戦ってくれている、仲間たちが、進むべき方向を共有できたことで、明らかにプロジェクトの状況が改善した。
構造(Large-Scale Structure)
16章は、大きなドメインモデルの構造設計の話。
単純にいえば、ドメインモデルの内部も「レイヤーアーキテクチャ」が有効だよ、ということ。
いろいろなドメインオブジェクトを複数のレイヤに分けて、
・役割や意図を明確にする
・できるだけレイヤ間を疎結合にする
こうすることで、モデルがわかりやすく、扱いやすくなるよ、という話。
ファウラーの「アナリシスパターン」や Hruby の「ビジネスパターン」にもでてくる「全体の構造」をわかりやすくする時の、基本パターンですね。
ドメインオブジェクトのレイヤ構造の考え方は、小さなモデルでも重要だし効果的だと思っている。
ここらへんは、別の記事で、具体的に取り上げようと思っている。
来年はどんな年になるのかな?
来年もしばらくは、頭の整理や充電にあてる時間がとれそう。いいんだか、わるいんだか。
ここにきて、いくつかのクライアントに出向いて、現場で、基本的な設計や、プロジェクトの進め方をアドバイスすることが続いた。
格安というか、ほとんど無償のコンサルティングですね。
いままでとは違った会社やドメインに接することは、発見や刺激があって面白いことは面白い。
スポットで、少ない情報を元に、出たとこ勝負のアドバイスも、ある意味、腕の見せ所だとは思っている。
そうはいっても、気の利いた、気心の知れたメンバーで、小さなチームを組んで、じっくりと、ひとつのシステムを仕上げることに専念したい気持ちも、もちろんある。
あるいは、未知のメンバーと、新チーム結成、とかも、刺激がありそうだなあ。
隔週で、ドメイン駆動設計の勉強会を開いて、このブログに、まじめにいろいろ書くようになった。
その中で、知り合った人たちとの交流は、ほんとうにいろいろな発見と刺激があった。
勉強会は来年もぜひ続けようと思う。
ブログも状況が許す限り、がんばってみよう。
来年は、仕事のほうは、どうなるのかな。
そういえば、ここ数年、営業して仕事をとったことがないなあ。
基本、
・来るもの拒まず
・なんでもご相談に応じます
てな感じで、なんとかやってこれた。
来年もこんな調子で、いつものごとく、ある日、突然、火を吹いたプロジェクトとか、短期決戦の案件が飛び込んできて、「なんとかしてくれ」「なんとかしましょう」モードになっちゃいそうな気もする。
「ドメイン駆動設計」にこだわるようになってから、どんな案件、相談も、なんか、同じ考え方、やり方で、それなりに、いけそうな気がしている。
「ドメイン駆動設計」が、未経験な領域とかでも通用するのか、効果があるのか、新しい案件で、トライアルしてみたい、というのが今の素直な気持ちかな。
それでお金がついてくれば、いうことないけど、まあ、今までと同じように、割りの合わない仕事を、「面白そう」と言うだけで、やっちゃうんだろうなあ。
今の私に必要なのは、気の利いた技術者仲間ではなく、そろばん勘定がしっかりした番頭さんなのかな。
でも、やっぱり、設計をみんなでわいわい、がやがや、やるのが、一番ですけどね。