読書メモ：ドメイン駆動設計入門ボトムアップでわかる！ドメイン駆動設計の基本 4

DDD自体が複雑な概念なので、その用語とパターンに集中して解説する入門書のメモの4回目。

Chapter13 複雑な条件を表現する「仕様」

条件判定を行うロジックを別のドメインオブジェクトに切り出したものが「仕様」。

条件判定のロジックは重要なドメイン知識であるため、独自のドメインオブジェクトに配置したいというのと、DBにデータを格納するリポジトリに置きたくないということで利用されるらしい。

OutSystemsなら、Core BusinessレイヤーのモジュールにActionとして配置することになる。「仕様」という概念に対応させるなら、それがわかりやすい命名規則を用意したいところだが、[Cheat Sheet] OutSystems Module Naming Convention辺りにはしっくり来るものはない。流用するなら、Business Logicということでモジュール名に_BLとかつけておく。仕様を使う機会が多いなら独自の名前（Specとか？）を考えても良い。

Chapter14 アーキテクチャ

ドメイン駆動設計にとって「アーキテクチャは決して主役ではない」（PAGE 469)

ドメイン駆動設計がアーキテクチャに求めることは、ドメインオブジェクトが渦巻くレイヤーを隔離して、ソフトウェア特有の事情からドメインオブジェクトを防衛することです。それを可能にするのであれば、アーキテクチャがどのようなものであっても構いません。（PAGE 475)

レイヤードアーキテクチャ、ヘキサゴナルアーキテクチャ、クリーンアーキテクチャといった例が説明されている（オニオンアーキテクチャはなかった）が、本章で繰り返し言われているようにドメインを他の要素から分離すればよいのであれば、OutSystemsのArchitecture Canvasを元にアーキテクチャ設計を考えるのでも良いということ。

Architecture Canvasも

アーキテクチャは方針です。何がどこに記述されるべきかといった疑問に対する解答を明確にし、ロジックが無秩序に点在することを防ぎます。開発者がアーキテクチャが示す方針に従うことで「何をどこに書くのか」に振り回されないようになります。（PAGE 474)

という役割は果たせる。ドメインオブジェクトのOutSystemsにおける実装パターンは検討して、アーキテクチャ設計方針に反映しておいたほうが良さそう。

Chapter15 ドメイン駆動設計のとびらを開こう

もっとも重要なことはドメインの本質に向き合うことです。技術的なパターンは絶対的な答えとして君臨するものではなく、ドメインの本質に向き合い、それを上手くコードで表現するためのサポート役として機能します。（PAGE 507)

つまり、OutSystemsでDDDを実現するなら、OutSystemsの制約の範囲内で「ドメインの本質をうまく表現できる」パターンを作り上げ、なおかつそれを必須ではなくサポートとして利用することが必要。

OutSystemsの公式ドキュメントでDDDに言及している部分では、チームやアプリケーションへの分割までを範囲としていて、パターンについては何も言っていない。各企業でパターンを作り上げる必要がありそう。

ドメインエキスパート（業務の専門家）と開発チームが共通の語彙リストとして制定するのが、ユビキタス言語。同じドメイン内でも、ユビキタス言語が異なる場合にはシステム的に別物とし、異なる場所で境界を設ける。これを境界付けられたコンテキストと呼ぶ。

OutSystemsのDDD情報まとめにも書いたが、この境界付けられたコンテキストの単位がArchitecture Canvasの作成単位としても合っていそう。

感想

この本は、ドメイン駆動設計を学習するのに重要な

概念を抽出するモデリング
概念を実装に落とすときに利用するパターン

の後者を解説し、より本格的なドメイン駆動設計の学習に備えることらしい。

まだドメイン駆動設計の原典の方は読んでいないが、パターンの解説はある程度頭に入った。

なお、この本に出てくるサンプルコードはC#で、最初の数章に出てくるものはかなりシンプルでC#を知らなくても困らない。中盤から、実装自体が難しいというよりもC#で利用するライブラリや特有の機能を前提としたものが増えて厳しくなる。とはいえ、オブジェクト指向開発経験者奈なら苦労するほどではない。