不味いDDDと美味しいDDD

「とんこつラーメンは不味い」
と言われたらどう思いますか？
本当でしょうか？
いえ、違いますよね

「不味いお店があれば、美味しいお店がある」

これが本質です。

これは食べ物だけではなく、
アーキテクチャも同じだと思います

よくクリーンアーキテクチャとMVCどちらがいいか議論がされている記事を見かけますが、なぜかディレクトリ構成レベルまでの議論はされていないことが多いです。

つまり、同じアーキテクチャ思想でも異なるディレクトリ構成である可能性が高いのです。

本来であれば、ディレクトリ構成までも議論して、最適な構成を議論すべきです。

にもかかわらず、「クリーンアーキテクチャを一度体験したけど、不味かった」という方もいれば、「クリーンアーキテクチャめちゃ美味しかったよ」という方に分かれており、YES OR NOで白黒はっきりさせる議論ばかりでした。

自分が思うに「失敗したアーキテクチャは何が原因で使いづらかったのだろうか？」と議論すべきだと思います

そういった意味合いで過去に作成したスライドになります

Transcript

1. とんこつラーメンは不味い
2. どう思いますか？
3. 本当でしょうか？
4. 不味いお店もあれば、 美味しいお店もある
5. アーキテクチャも同じでは？
6. 良いDDDもあれば、 悪いDDDもある
7. MVC vs DDD よくある議論
8. 同じディレクトリ構成 なのかな？
9. なぜかディレクトリ構成 は議論されない
10. 良いDDDを使って賛成派、 悪いDDDを使って反対派
11. 良いDDD × 悪いDDD
12. コードを仕様書にする
13. フレームワークの構成ではなく サービスを優先した構成
14. 現実世界で考えよう
15. 想像してみてください...
16. すべてのプロジェクトの wordが1つのフォルダに 入っていたら...。
17. ファイルの種類ごとに管理 PDF Excel Word img ファイル数が少ないと管理で困らない
18. ファイルの種類ごとに管理 PDF Excel Word img 数が多いと目的のファイルが見つけにくい 後々、困る
19. 担当プロジェクトのファイルを 見つけるだけで一苦労 ですよね？
20. MVCはこれに近いです
21. 最初はいいけど、 関連性が見えず 保守で苦労をする
22. 作った本人しかわからない
23. これがMVCの問題です
24. なので、どの会社も....
25. フォルダで整理しています
26. PDF Excel Word img 実際に会社はどう整理している？
27. ファイルの種類ごとに管理 提案書 仕様書 ワイヤー アイコン プロジェクトごとにファイル管理する プロジェクトA 提案書 仕様書 ワイヤー アイコン プロジェクトB 用途ごとにまとめる 用途ごとにまとめる カプセル化 => 影響範囲が明確。必要分だけ確認 カプセル化
28. エンジニア的にいうと モジュールで分けます
29. 影響範囲が制限されている だから、変更しやすい
30. ファイルの種類ごとに管理 仕様書 責務が分かれている 仕様書の見直しが必要な場合、 仕様書ディレクトリを確認すればいい。
31. 責務が分かれていると 必要な箇所だけ編集できる
32. 何が無関係か明確である
33. 新規メンバーも着手しやすい
34. ファイルの種類ごとに管理 提案書 仕様書 ワイヤー アイコン プロジェクトごとにファイル管理する プロジェクトA 提案書 仕様書 ワイヤー アイコン プロジェクトB 用途ごとにまとめる 用途ごとにまとめる カプセル化 => 影響範囲が明確。必要分だけ確認 カプセル化
35. 大多数の会社で同じですよね？
36. では、コードはどうですか？
37. ファイルの種類ごとに管理 提案書 仕様書 ワイヤー アイコン MVCとDDDもこれと同じ DDD アーキテクチャ構成 => 複雑になると混乱 MVC PDF Excel Word img MVC => 担当箇所が明確
38. つまり、 フレームワークの機能ではなく、 サービスの機能に合わせるべき。
39. 機能の仕様がわかりやすい
40. 別にそこまでしなくても いいんじゃない？
41. 問題です。
42. あなたのプロジェクトの仕様は どこにまとまっていますか？ （※コードにおいて）
43. パッと答えられなかった場合は、 新規メンバーも困る可能性が高い
44. DDDでは、 Domain層に仕様を書く
45. Presentation層 Application層 Domain層 Infrastructure DDDの構成 Controller, Request, ViewModel, Resource ApplicationService, Command DomainService, DomainModel, ValueObject Repository, Factory 画面などに関わる部分 CRUDなど機械的に必要な処理 仕様に関すること AWSやDBなど機械に依存する箇所
46. Controller Serivce Repository
47. Controller ApplicationSerivce DomainSerivce Repository サービス層を二つにわける
48. ApplicationSerivce DomainSerivce プログラムに必須 仕様に関すること CRUD publish()
49. アプリの仕様は DomainServiceをまずみる
50. Domain層 DomainService：サービスの仕様 DomainModel：オブジェクトの仕様 ValueObject：カラムの仕様 省略
51. 注意点 Domain層は必須ではない。 複雑な仕様になったら、つくる
52. レイヤー重視型 モジュール重視型
53. レイヤー重視型 レイヤーごとに機能のディレクト リが存在する
54. 機能単位にモジュール分け モジュール内にレイヤードア ーキテクチャを採用する モジュール重視型
55. 本質 可読性を上げて、仕様がわかる 責務がわかれている
56. 注意点 DDDを目的にしない。 仕様がわかるコードが本質