ここで、デザインパターンとは何かとかどんなパターンがあるかという話しは置いておいて・・・

デザインパターンをモデルに適用する

デザインパターンは、オブジェクト指向技術を技術的に使用する上で、さまざまなコンテキストで頻繁に直面する問題を解決してきたものです。なので、デザインパターンのカタログでは技術的な用語で紹介されています。

このデザインパターンをドメイン駆動設計で適用する上で注意する点は、パターンの考え方が本当にドメインの概念に合うかどうかというところです。
このことはこの章で何度も言われているところですね。

例では、ストラテジーパターンとコンポジットパターンが挙げられています。
ストラテジーパターンをドメイン駆動設計に当てはまる際には、

デザインパターンとしてのストラテジーに対する従来の見方は、さまざまなアルゴリズムを置き換える能力に焦点をあわせているが、ドメインパターンとして使う場合には、プロセスや、ポリシーのルールに代表されるような概念を表現する能力に焦点を合わせている。

デザインパターンとオブジェクト指向とドメイン駆動設計

オブジェクト指向技術と合わせて広まったデザインパターンですが、デザインパターンが理解できれば、エンジニアとしてレベルが上った、保守性の高いソースコードが書ける！というのはちょっと誤解がありそうです。

複雑なドメインに対して、ドメインの概念に合わせることを考えずに複雑なデザインパターンを適用すれば、結局ソースコードが複雑になるだけですよね。

やはり、ドメイン駆動設計を理解して、ドメインの概念に合った場合にのみ、デザインパターンを選択することが大事ですね。

それから、Gofのデザインパターンカタログを全て使えないとだめですか？という質問をときどき受けることがあるのですが(質問されるほどレベル高くないだろというツッコミは置いておいて・・・)、ドメインの概念にはなかなか合わないようなパターンもあるので、無理やり全部理解しようとするよりは、ドメイン駆動設計を理解しに行った上で、概念的に適用できるパターンはないかなとカタログをパラパラめくるような使い方をする方がいいかもしれませんと答えています。

実際、ドメイン駆動設計本でもフライウェイトパターンはドメインモデルにおいては、一致するものがないと言っています。(値オブジェクトに対して適用した例は５章で紹介されてますね。ただ、エンティティで使用できるものではないので、ドメインの概念と一致しているとは言い難いということです。)

インタプリタパターンも、今のところ例が思いつかないと言っていますね。