レガシーをぶっつぶせ。現場でDDD！2nd 「インプット＜アウトプット！」のクロージングワークショップの中で議論した内容を簡単にまとめた記事になります。
インプット＜アウトプットということで、初めてですが少しでも残ればと思い投稿します。
結論：軽量DDDは有り！
結論から書いてしまいますが、クロージングワークショップの結論としては軽量DDDは有りという雰囲気で終わりました。
増田（@masuda220）さんにファシリテートしてもらいながら、インプット＜アウトプットということで、一人一回以上の発言をルールとして議論していきました。
以下に簡単にですが、議論した内容を記載します。
（ホワイトボードの写真撮り忘れました・・・。）
そもそも軽量DDDとは？
- DDDのValueOvject、Entity、Repositoryなど技術的な部分のみを取れ入れDDDを行うという実践ドメイン駆動設計（IDDD）の中で、アンチパターンとして語られているもの。
- コアドメイン、サブドメイン、境界付けられたコンテキスト、ユビキタス言語などを意識していないもの。
キーワードは以下の表の通り
| 戦術的 | 戦略的 |
|---|---|
| 値オブジェクト | コアドメイン |
| エンティティ | サブドメイン |
| リポジトリ | 境界付けられたコンテキスト |
| ユビキタス言語 |
その他のキーワードとして
- クリーンアーキテクチャ
- オニオンアーキテクチャ
- オブジェクト指向
- トランザクションスクリプト
実際、軽量DDDは有りだと思うかどうか？
- 有りだと思っている。値とロジックを一緒にしておくことでオブジェクト指向的になり、コードは整理される。
DDDとオブジェクト指向の違いは？
- DDDもオブジェクト指向の一種ではないか。DDDはその中でもドメイン部分に注力する。
- そのせいかファイルの入出力などはトランザクションスクリプト的な書き方になりがち...。
クリーンアーキテクチャやオニオンアーキテクチャを適用しないとDDDにならないか？
- アーキテクチャとDDDは切り離して考えられる。
- 違うアーキテクチャを採用してもDDDをすることは可能。
軽量DDDから重量（？）DDDに移行できるのか？そもそも境界線は？
- コアドメインやサブドメインを意識してクラスを考え始めたらちゃんとしたDDDではないか。
- ユビキタス言語を活用して、ドメインエキスパートと話ができたらDDDではないか。
ドメインエキスパートがいないとちゃんとしDDDはできないか？
- ドメインの分析はドメインエキスパートが必要。
- ユビキタス言語を浸透させていくためにもドメインエキスパートの存在が必要。
- ただ、スタートアップのプロジェクトの場合、ドメインエキスパートがいないのでは...？
ラスト2分増田さんより一言
『エヴァンス本の中ではむしろ値オブジェクトなどの戦術的な部分があった上で、戦略的な部分が考えられると明確に書かれている。私もそちらの考え。』
※もっと色々言いたかったみたいですが、一人一回以上の発言のルールのために、控えていたご様子（笑）
感想
個人的には「軽量DDDは有り」と思って、議論に参加していました。
理由は単純でコードをきれいに書きたいと考えているとどうしても戦術的な部分に力が入ってしまうという思いからでした。
そして難解なエヴァンス本の中でも値オブジェクトとかエンティティってわかりやすく、エンジニアとしてはやってみたいと思うじゃないですか（笑）
今回議論の中で、他の方々も基本的には「軽量DDDは有り」と思っている方が多かったように思います。
同じような悩みや思いの共有ができて、参加して非常に良かったです。
今後も継続してこういったワークショップには参加していきたいと思います。
そして、腹落ちさせるためにも少しでもアウトプットしよう！・・・という気持ち。
謝罪
完全に記憶だけを頼りに書いたので、抜け漏れ、間違いあるかもしれませんが、ご容赦ください。
当日参加されていた方で、明らかな間違いに気づいた点があればコメントください。