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

2023/6/23 書籍

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

Chapter10 データの整合性を保つ

Chapter9もそうだが、DDDには直接関係しない話題の章。

重複しないことを担保する方法としてリレーショナルデータベースのユニークキー制約に頼るのは、まさに特定の技術基盤に依存することを意味します。（PAGE 348)

というわけで、あるテーブル内での一貫性を保つために、

  • テーブルにユニークキーを付与して整合性を確実に保ちつつ
  • ドメインオブジェクトのコードで一意制約があることがわかる記述も行う（ドメインの知識をコードに残しておく）

ことが勧められている。

この点、OutSystemsでは、Entityに付与されているIndexはIDE内で隣り合った場所で見られるので、EntityのIndexに任せてもいい気がする。

その場合、開発者はEntityへの更新ロジックがあったら、EntityのIndexくらいはチェックする注意深さを要求されることになる。と、考えると、コードでチェックにも価値はある。プロジェクトごとに判断かな。

ちなみに、OutSystemsのトランザクションはWebリクエスト処理中で最初にDBアクセス発生時に自動で開始し、リクエストの一連の処理が終わる時に自動コミットされる。Actionを使って明示的にコミット・ロールバックすることも可能。

Chapter11 アプリケーションを1から組み立てる

アプリケーション作成の大まかな流れとして

  1. 求められている機能を確認する
  2. 機能を実現するのに必要なユースケースを洗い出す
  3. ユースケースを実現するのに必要な概念を抽出し、ドメインオブジェクトを作成する
  4. ドメインオブジェクトを利用するアプリケーションサービスを実装する

OutSystemsだと、1,2の辺りは違いはなく、3でArchitecture Canvasで言うCore Businessレイヤーの要素を作成し、その後で4でEnd Userレイヤーの要素を作成する、という整理になるはず。

3,4で必要な部品があればFoundationレイヤーの要素として作成する、という感じか。

Chapter12 ドメインのルールを守る「集約」

複数のエンティティを更新する単位となるのが「集約」。

複数のエンティティを区切る境界を定め、ルートとなるオブジェクトを介してのみ境界内に対する更新を行えるようにする。

これも、OutSystemsにマッピングするならCore Entityパターン。オブジェクトという概念がないので、PublicなActionを定め、境界内に対する更新処理をそのActionに集約することで実現できる。

トランザクションの単位も集約にする、という記述もある。OutSystemsは基本的にリクエスト単位がトランザクションの単位であるため、必要な場合のみ集約単位でコミットするほうが違和感の少ない処理になりそう。