読者です 読者をやめる 読者になる 読者になる

Some Days You Get the Bear

IT系エンジニアの、日々の気づきや考えたこと。

DDDとはこういうことなのか

♪今年のブクマ、今年のう・ち・に!      ← 書いてるうちに年こしちゃったね

というわけで、もうひとつの ”長くてほったらかしだったやつ” を読む。

ドメイン駆動設計入門 - Digital Romanticism

正直これまでドメイン駆動設計って「言葉を知っている」という程度のものだったのですが、
この和智さんのブログを読んで、もうちょっとは先に進むことができた感じがしました。

以下に、私が今回理解できた部分を抽出して、少しでもコンパクトにすべく、ショートバージョンとして抜粋してみます。


■オブジェクトとは?

大げさな表現をすれば、「僕らは言葉によって世界を切り分け、そこに名前を与え、意味に囲まれて生きている」ということですね。あるモノに意味を見出し、他のモノと切り分け、そこに名前を与えることで自分たちの世界を構築しているのが人間だ、ということです。オブジェクト指向において、オブジェクトに表現させようとしたのも、実はモノ自体ではなく、「概念」すなわち「名付けられ、意味を与えられたユニット」なのです。

■モデルとは?

1979年(30年前!)に書かれたMVCの原典では、モデルは「知識の表象」とされています。ユーザの頭の中にある知識/メンタルモデルを写し取るものだと考えられていたんですね。「メンタルモデル」とは、私たちの世界のとらえ方、言葉によって頭の中に構築された世界の像です。それをコンピュータの中に写し取るために登場するのが、オブジェクト指向というパラダイムです。メンタルモデルを構成する概念をクラスとして表現することで、メンタルモデルを写し取ろうとしたのです。

こうした、概念を表現するオブジェクト指向というパラダイムと、オブジェクト指向を用いてメンタルモデルをコンピュータの中に持ち込もうという発想がドメイン駆動設計の出発点となります。

ドメイン駆動設計とは?
ドメイン("domain")とは、(...)要するに「業務領域」「事業対象」などと考えれば分かりやすいでしょうか。

私たちのメンタルモデルは「言葉」あるいは「概念」によって構築されているものでした。これは専門家が持つドメインモデルに関しても同じことが言えるため、ドメインモデルを共有する上での武器もやはり言葉ということになります。その時に重要なのが、同じ言葉を使った時に、確実に同じ概念をイメージするということです。言葉は実体を持つものではなく、世界を切り分けるものでした。この境界線の引き方は人によって異なりますから、ある単語を聞いた時に自分が想起するイメージが、その単語を話している人のイメージと同じである保証はどこにもありません。したがって、ある概念は単独で理解することはできず、他の概念との関係において理解する必要があるということになります。

こうしたモデルを構成する言葉は、会話やドキュメントなど、プロジェクト内のあらゆる場所で使われるべきだと考えられています。このプロジェクト内にあまねく行き渡った言葉が、ユビキタス言語("Ubiquitous Language")というパターンとして説明されます。さて、このあらゆる場所という表現には、当然コードも含まれています。ユビキタス言語によって構成されたドメインモデルを、文字通り「反映」させてソフトウェアを作ること、それがモデル駆動開発("Model Driven Development")です。このユビキタス言語とモデル駆動開発ドメイン駆動設計においてもっとも重要な2つのパターンと言えるでしょう。

■プロセス

ドメインモデルの共有と構築を軸としたドメイン駆動設計にとって、その開発プロセスアップフロントなものではなく、イテレーティブなものとなります。まず開発者は、ドメインの専門家が持っているモデルを共有するため、頻繁にコミュニケーションをとる必要がありますし、専門家にしてみても、頭の中に描いているモデル自体が実は完成されたものではなく、フィードバックを受けて変化する可能性があるものなのです。こうしたモデルの変化について、Evansは深さ("deep")という言葉で表現しています。モデルが深みを増していくんですね。

こうしたモデルの深化において主要な役割を果たすのも、やはり言葉です。うまく表現できなかったもの、あいまいだったものが、それを示すある言葉を与えられることで、一気に明確になるということは少なからず経験があるのではないでしょうか。これについて、Evansは「より深い洞察」と表現しています。こうしたモデルの変化は直線的に起こるだけではなく、ある日突然大きく変化することもあります。こうしたブレイクスルーは日々モデルを洗練させていく行為の先に突然訪れるものだとされています。

■文脈

ある言葉は他の言葉との関係において一定の意味を持ちますが、この意味の同一性は無制限に保証されるわけではありません。(...)そして、ある文脈には有効範囲が存在します。Evansは境界づけられた文脈("Bounded Context")という概念を用いて、文脈が持つそうした有効範囲を明確にするよう促します。さらに、企業レベルでシステムが統合される場合には、異なる文脈が共存することになりますので、それら文脈間の関係を文脈の地図("Context Map")として描き出すことが重要であるとされています。

■抽出

ドメインモデルを作り上げる行為もある意味で専門家の目から見た本質を抽出する行為でしたが、同じことはより広大なコンテキストマップに対しても実施することができます。こうして最も価値のあるコアドメイン("Core Domain")を識別し、それを共有した上で、重要度に適した投資を行うことが必要になるのです。


普段の我々のシステム開発の中でも、ドメイン駆動設計を意識することなく、
そのプロジェクト・顧客の中で、イメージが共有される言葉というのは、たくさん現われ作り出されています。
ドメイン駆動設計というのは、難しいもののように感じていましたが、今回この記事を読んで思ったことは、
こういう言葉・共通言語をちゃんと表明して意識して、ブレずにきちんと共有して使っていくことで、
みんなが理解できるブレない設計へつないでいけるものなのですよ、と言っているわけで、
何か特別なことを言っているわけではないのだと思いました
(尤も、入門編なので、もっとむづかしい話がはしょってあるんだと思いますが)。
自分の中でのハードルが少し下がってとっつきやすくなりました。和智さんありがとうございます。

それから、言語の共有化のあたりは、SECIモデルと通ずるものがあると感じました。
DDDとアジャイルの関係は、単にイテレーティブな設計というだけでなく、こういうところにもあるように思いました。

では。



2016-04-03
和智さんのインタビューが出てたので。
www.fostercareer.com

広告を非表示にする