#evans2003

概念的に凝集されたメカニズムを切り分けて別個の軽量なフレームワークにすること。特に、形式主義や十分にドキュメント化された種類のアルゴリズムに気を配ること。意図の明白なインタフェースを用いてフレームワークの機能を他から使えるようにすること。これで、ドメインの他の要素は問題を表現すること（「何が」）に集中でき、複雑な解決（「どのように」）はフレームワークに移譲できる。

改善されるにつれて、モデルは、プロジェクトの中を流れ続ける情報を体系化するためのツールとなっていく。

結局、何か月も知識をかみ砕いた後で我々が気づいたのは、貨物の取り扱い、すなわち物理的な荷積みと荷下ろしや、ある場所から別の場所への移動などは、ほとんど下請け会社や社内の業務担当者によって行われているということだった。輸送業エキスパートから見れば、関係者の間で連続して責任が移動するということだったのだ。そうした荷主から地元の輸送会社へ、さらに輸送手段を複数経由して最終的な荷受人までという法的かつ実務的な責任の移動を、1つのプロセスが管理していた。貨物が倉庫に置かれたまま、重要な手続きが行われることもよくあった。あるいは、貨物の物理的移動を伴うような複雑な手続きが行われでも、それが輸送会社のビジネス上の意思決定とは関係ないこともあった。重要視されるようになったのは、輸送日程の手配よりも、船荷証券などの法律書類や支払い免除につながるプロセスだったのだ。

通常、ドメインエキスパートは、自分の頭の中で起きているプロセスがいかに複雑かを意識することなく、仕事をする中でこれらのルールをすべて調べて矛盾を調整し、常識で考えて隔たりを埋めている。だが、こういうことはソフトウェアにはできない。ソフトウェアエキスパートと密接に協力する中で、知識をかみ砕くことによって初めて、ルールが明確となり、具体化されて、折り合いがつけられるか、あるいはスコープの対象外とされるのである。

PCBの例で示したように、モデルによってとらえられる知識は、「名詞を見つける」ことに留まらない。ビジネスの活動やルールも、ドメインに含まれるエンテイティと同じように、ドメインにとって中心的なのだ。

機能の開発が取り止めになったとはいえ、初期の作業は不可欠だった。主要なモデル要素がそのまま残ったということもあるが、それよりも重要なのは、初期の作業が知識のかみ砕きというプロセスを始動させ、それによって以降の全作業が効果的に行われたということだ。すなわち、チームメンバ、開発者、ドメインエキスパートが同じように知識を得て、共有された言語が芽を出し、実装を通してフィードバックループが完結した。発見の旅は、どこかから始めなければならないのだ。

高度に生産的なチームは、自分たちの知識を意識的に育てて、継続的学習（Kerievsky2003）を実践する。開発者にとって、これが意味するのは、（本書にあるような）一般的なドメインモデリングのスキルと合わせて、技術的な知識を向上させるということだ。ただし、その時に取り組んでいる具体的なドメインについて真剣に学習することも、ここに含まれる。

一方、すべてのプロジェクトから知識は流出している。何かを習得した人は他の所へ移動する。再編成によってチームはばらばらとなり、知識が再び断片化してしまう。重大なサブシステムがアウトソーシングされると、コードは納品されても、知識はついてこない。典型的な設計アプローチの場合、コードとドキュメントは、苦労して手に入れた知識を使える形式で表現しないから、口頭での伝承が何らかの理由で途切れたら、知識は失われてしまう。