エリック・エヴァンスのドメイン駆動設計その2 〜第1章知識を噛み砕く〜

さて、第1章。
知識を噛み砕くとはどういう意味か、
そしてそれはどれだけの効果があるのか？

著者は以下のように行った。著者はこれを「効果的なモデリングの要素」または「知識を砕くこと」と表現している。

自身の経験を元に、深く理解できたのは次のもの。

プロジェクトが進むにつれ、我々全員がモデルから用語をそのまま取り出し、モデルの構造と矛盾しない文章にまとめて、通訳しなくても性格に理解し合えるようになった。

チーム内で共通言語が出来ているとコミュニケーションが円滑になる。これは間違いない。絶対に正しい。
言語が統一出来ていないプロジェクトは誤った理解や解釈が行われて顧客が望むものが作られない。

オブジェクトには、ふるまいと、守るべきルールがある。モデルは単なるデータスキーマではなく、複雑な問題を解決するのに欠かせないものだった。モデルは様々な種類の知識を捉えていたのだ。

getterとかsetterだけがあるのがモデルじゃない。
モデルはそれ自体の振舞と制約を持っている。

役に立たない、あるいは核心でないとわかった概念は取り除かれていったことである。

不要なメソッドを削除する、存在しないモデルを考え出すのは意思決定が難しい。
でもこれは製品の品質に良い影響を与えるはずだ。

ブレインストーミングと大量の実験が持つ創造性は、モデルに基づいた言語を通じて活用され、実験を通じたフィードバックグループによって鍛えられたものだ。

ディスカッションのない組織は発展しない。
ディスカッションして製品は洗練されていく。

知識を噛み砕くことは重要である。

優秀なプログラマは、当然、抽象化することから始め、より多くの処理を行うことのできるモデルを開発する。ただし、その背景にあるのが技術だけで、ドメインエキスパートとの共同作業がない場合、その概念は素朴なものにしかならない。

モデルは実用的で役に立つものでなければならない。また、アプリケーションがシンプルに実装され、理解しやすくなるように、モデルは厳密でなければならない。

顧客のビジネスが存在しそのビジネスを最大化するためにソフトウェア開発チームが存在している。
ドメインエキスパート、チームメンバが連携して知識を噛み砕き、理解し合うことで洗練したモデルが作られる。

知識を噛み砕くことによって初めて、ルールが明確となり、具体化されて、折り合いがつけられるか、あるいはスコープの対象外とされるのである。

知識が明確になることでスコープが定義できるようになる。
スコープ定義ができたらそれをチームに落とし込めば良い。

実際のプロジェクトでは、継続的学習によってチームメンバもドメインの複雑さに対応できるようになるのであり、有用で明確なモデルを作るにあたって、ドメインとモデリングテクニックの両面においてさらなう洗練が求められることも多い。

要件を外さないための知識の噛み砕き。
チームとして有機的に活動するための知識の噛み砕きなんだ。