DDD/Chapter Eleven. Applying Analysis Patterns

11章　アナリシスパターンの適用（p293～） †

P293-1,2,3
Deep Modelsの作成ははドメインに関する多くの学習、多くの会話、多くのトライ＆エラーによってもたらされるコストの高い作業である。
アナリシスパターンは、私達をそんなコストの高い作業から開放してくれる。

ビジネスモデリングにおける共通の構造を表現した概念の集まり．
それは一つのドメインに関連するものもあれば，複数のドメインに渡るものもある．

P294-1,2
アナリシスパターンは、工学的な手法ではないが、特定のドメインにおいては道標（モデリングのテンプレート）となり、困難に面している者に価値ある起点を提供してくれる。
（ただし、欠点は実務的なデザインの為の思考が無い事)

新しい[会計の]慣例を構築する時、転記に関する新しいインスタンス間のネットワークを作る。
私達はシステムを止めることなく、いかなる再編集・再構築なしに、これを達成する事ができる。
私達が転記に新しいサブタイプを必要とする時、不可避な場面があるだろう。（極めて稀であるが）[p151]

P294-3
熟成されたプロジェクトでは、しばしば経験からモデル選択がなされる。
様々なコンポーネントの多数の実装が試され、いくつかは製造、運用フェーズにまで適用される。
経験が有効であった場合、多くの問題は回避される。
アナリシスパターンは、経験のようなものを他のプロジェクトからもたらしてくれるという意味では、最も適している。

P293-4
次からファウラーの「Inventory and Accounting」から２つの例が紹介されるが、パターンの紹介でも、ましてやパターンの完全な説明でもない。
DDDのプロセスへの統合を描いている点がポイントである。

恥ずかしながらアナリシスパターンが分かっていません。やっちまったな～って感じです（笑）
誤訳があれば突っ込みお願いします。