BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース コンテキスト境界を考える - Nick Tune氏のDDD Europeでの講演より

コンテキスト境界を考える - Nick Tune氏のDDD Europeでの講演より

ブックマーク

原文(投稿日:2020/02/15)へのリンク

ソフトウェアにおいて、システムを分割してモジュール化すべき理由はたくさんある — 先日アムステルダムで開催されたDDD Europe 2020の基調講演で、Nick Tune氏はこのように述べた。大規模システムを部分的に捉えることで、認知負荷(cognitive load)を低く抑えることが可能になる。システムの各部分を、自律的かつ独立的に開発することができる。ビジネスの観点から、より詳細な投資管理が可能で、重要な部分により多くのリソースを配置することができる。講演の中でTune氏は、モジュラリティとコンテキスト境界の設定および分析によって、設計時や改良時のモデリング上の選択肢を多くすることができる、と論じている。

ロンドンを本拠に技術リーダ兼コンサルタントとして活動するTune氏の講演は、我々はバウンダリやモジュール分割を論じる場合、バウンダリを強調し過ぎているのではないか、という指摘から始まった。バウンダリの概念には固定的な分割が暗黙的に含まれているが、それではうまくいかない、と氏は言う。ドメイン駆動設計(DDD)とコンテキスト境界の中核をなすのは言語であり、言語をより理解することがバウンダリの理解を進める上では重要だ。境界の外側から境界の中へと来る影響を理解しなければならない。その影響を運ぶのは、通常は言語なのだ。コンテキスト境界は言語の防御壁だが、我々は境界に注目するあまり、言語の部分を軽視することが少なくない。境界外からの影響は、我々の理解や予想よりもはるかに多い。ことばの持つ意味が、境界の内と外でまったく違う場合があるからだ。それゆえ我々は、言語のドメインモデルを理解して、それをDDDで活用しなければならない、と氏は主張する。

DDDにはコア、支援、汎用という3つのサブドメインの概念があるが、これらはやや不明確で定量化が難しいのではないか、とTune氏は考えている。コアドメインになるにはビジネス上の差別化要因を高いレベルで備える必要があるが、それは同時に、ある種の複雑性を持つことでもある。非常に高度なビジネスの差別化要因と高い複雑性を伴うものがあれば、それは間違いなくコアである。ここで優位に立つことができれば、市場の専有が可能になる。複雑性のため、競合他社がキャッチアップすることも困難だ。コアドメインは時間とともに変わる可能性がある(may)という意見を耳にすることもあるが、Tune氏に言わせればそれは必然(will)である。進化は必ず起こるのだ。

もうひとつの例は、ビジネス上の差別化要因は高いが、非常にシンプルなソリューションのあるコアドメインである。これは危険視号だ。なぜなら、いかに差別化要因が高くても、競合他社が簡単にキャッチアップできるからだ。Tune氏はこれを"市場一番乗りのコア(first to market core)"と呼ぶ。一番乗りではあるが、競合他社が容易に追いつけるので、防御は容易ではない。

Tune氏は、予測していなかった、あるいは起きるはずのなかったものを、"ブラックスワン(black swan)"コアと定義している。この考えには、汎用的なものはすべてアウトソースすべきである、というDDDコミュニティと対立する部分がある。多くの場合においてそれは真実だが、まれではあるものの、汎用的なものがコアドメインになる場合もある、とTune氏は指摘する。イノベーションはいつでも起こり得る、汎用ドメインがコアドメインに変化する可能性もあるのだ。Tune氏は次のように言う。

汎用ドメインというものは存在しません。

コンテキスト境界のもうひとつの側面は、チーム組織に関するものだ。これには興味深いダイナミクスが存在しており、我々はまだチームを適切に組織化する方法を見出していない、とTune氏は考えている。継続的デリバリのパフォーマンスと、相応の組織構造による疎結合のソフトウェアアーキテクチャとの間に相関関係があることを示す、データや研究も存在する。

この相関関係を説明するために、Tune氏は、ユーザとチームの対話方法に着目する。ユーザはプロダクトに対して、優れたカスタマエクスペリエンスを求める。チームの目標は、ユーザが望むものを理解して、このカスタマエクスペリエンスを実現するためのソフトウェアアーキテクチャを開発することだ。これはひとつのループであり、その速度を上げるためには、アーキテクチャとチームがともに適切な形であることが必要になる。このことは、組織とアーキテクチャに関係性が存在するというConwayの法則からも明らかだが、ビジネスは時間とともに進化するものであるため、アーキテクチャやチームも同じように進化しなければならない、ということもまた明らかだ。チームのコラボレーションの方法にはさまざまなパターンが存在するが、ドメインやアーキテクチャの進化の方法の違いによって、コラボレーションが時間とともに変化する方法も異なる、とTune氏は強調する。Eric Evans氏の"Domain-Driven Design bookには、これに関連した戦略的設計がさまざまな部分で取り上げられている。

結論としてTune氏は、いくつかの予測をしている。ソフトウェアはドメインを表現するものであるのだから、ドメインの動作を記述するべきであり、我々の使うドメイン言語は明確なコードであるべきだ。我々はまだそこにたどりついていないが、Cyrille Martraire氏の著書"Living Documantation"は、コードでドメインを文書化する上で取るべきアプローチを示唆するものだ、と氏は考えている。開発者の進化は予測ではない。すでに起きている事実だからだ。DDDの初期に比較すると、今日の開発者の多くは、よりビジネスを重視した開発を行っている。クラウド内のインフラストラクチャ作業の自動化が進むことにより、開発者はよりドメインに集中するようになる。これにより、将来的に開発者は、よりドメインの専門家になっていくだろう、と氏は考えている。

Tune氏が講演で使用したスライドはダウンロード可能である。氏は2015年に発刊された書籍"Patterns, Principles, and Practices of Domain-Driven Design"の著者のひとりでもある。 

InfoQはMartraire氏の著書が発刊された昨年、氏とのQ&Aを行った。

カンファレンスのおもなプレゼンテーションは録画されており、今後数ヶ月内に公開される予定である。

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

BT