オレオレDDDを一から整理し直し。
まずは、レイヤーから。
レイヤー構成
Presentation
- 外部インターフェース（外部向け定義および操作）に関する機能を実装する層
- 「外部に対する表現」が主たる役割
Application
- ドメインを用いて機能を実現する層
- 判断／加工に関するロジックは実装しない
- 他システムとの連携（腐敗防止）でもある
Infrastructure
Domain
- 機能仕様を実装する層
- 「ドメイン（関心事）の実装」が主たる役割
考察
関心事に着目できる実装を目指す
ApplicationとDomainの実装を読めば、主な関心事を読み取れることが目標であり、そのためのレイヤー分割です。
表現と実装
「表現」は、画面やJsonなどの外部向けに提供する定義や機能、業務フロー（詳細手順ではない）のようなプロセス（サービス）の組み合わせ、という意味です。
「実装」はコードによって機能を実現することを意味しています。
例えば「表現」は、ドキュメントから自動生成した資産で事足りるようなものであり、「実装」はコードにより柔軟に対応（もしくはコードにより複雑さに対応）するもの、というイメージです*2。
MVCとの違い
レイヤーは論理的な整理という理解です。
今回の整理とMVCは何が違うの？と思われるところがあるかもしれません。*3
MVCと今回の整理を比較すると、PresentationはVC、ApplicationはM（もしくはCを含む）、Infrastructureは あえていえばM*4、DomainはM というのが私の理解です。
Infrastructureをレイヤーとして明確に分け、各層とはインターフェースを介して疎結合を実現する、というところがDDDの実装面で学んだの私なりのポイントです。そして、ここがMVCと混ぜて考えてしまい混乱してしまったところでもあります。*5
クライアントサイドは全てPresentationでも無い
SPA*6は、すべてPresentaionか？というと、それは違います。クライアント側はクライアント側でレイヤー分割をした実装をすべきです。
基本的な整理は同じで、Infrastructure層ではJsonやWebSocketによりサーバーからデータを取得したり、サーバーに更新指示をする、というイメージです。
テスト
各層を疎結合にするレイヤー構造であれば、プロジェクト（パッケージ）毎にリポジトリを設けることも可能です。
1つのプロジェクト（パッケージ）だと時間のかかるテストでも、分散して構成管理することで並列でテストを行うことも出来ます。
最終的に結合したテストは必要ですが、それ以前のビルドやテストを並列に実施できるメリットは大きいと考えます。*7
この辺りは、具体的な実装をしていく中で自分なりに分割・分散をやってみたTIPSを積み上げられればと思っています。
参考資料
www.slideshare.net
一旦まとめた後に見つけた資料。
Go言語だけれど 参考になるところが多そうなのでメモ
DDD超入門(後編) - Domain-Driven Designの適用Step - エンタープライズギークス (Enterprise Geeks)
