$30 off During Our Annual Pro Sale. View Details »

不味いDDDと美味しいDDD

 不味いDDDと美味しいDDD

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

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

これが本質です。

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

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

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

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

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

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

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

ぎゅう

September 22, 2022
Tweet

More Decks by ぎゅう

Other Decks in Marketing & SEO

Transcript

  1. とんこつラーメンは不味い

    View Slide

  2. どう思いますか?

    View Slide

  3. 本当でしょうか?

    View Slide

  4. 不味いお店もあれば、
    美味しいお店もある

    View Slide

  5. アーキテクチャも同じでは?

    View Slide

  6. 良いDDDもあれば、
    悪いDDDもある

    View Slide

  7. MVC vs DDD
    よくある議論

    View Slide

  8. 同じディレクトリ構成
    なのかな?

    View Slide

  9. なぜかディレクトリ構成
    は議論されない

    View Slide

  10. 良いDDDを使って賛成派、
    悪いDDDを使って反対派

    View Slide

  11. 良いDDD × 悪いDDD

    View Slide

  12. コードを仕様書にする

    View Slide

  13. フレームワークの構成ではなく
    サービスを優先した構成

    View Slide

  14. 現実世界で考えよう

    View Slide

  15. 想像してみてください...

    View Slide

  16. すべてのプロジェクトの
    wordが1つのフォルダに
    入っていたら...。

    View Slide

  17. ファイルの種類ごとに管理
    PDF Excel Word img
    ファイル数が少ないと管理で困らない

    View Slide

  18. ファイルの種類ごとに管理
    PDF Excel Word img
    数が多いと目的のファイルが見つけにくい
    後々、困る

    View Slide

  19. 担当プロジェクトのファイルを
    見つけるだけで一苦労
    ですよね?

    View Slide

  20. MVCはこれに近いです

    View Slide

  21. 最初はいいけど、
    関連性が見えず
    保守で苦労をする

    View Slide

  22. 作った本人しかわからない

    View Slide

  23. これがMVCの問題です

    View Slide

  24. なので、どの会社も....

    View Slide

  25. フォルダで整理しています

    View Slide

  26. PDF Excel Word img
    実際に会社はどう整理している?

    View Slide

  27. ファイルの種類ごとに管理
    提案書 仕様書 ワイヤー アイコン
    プロジェクトごとにファイル管理する
    プロジェクトA
    提案書 仕様書 ワイヤー アイコン
    プロジェクトB
    用途ごとにまとめる 用途ごとにまとめる
    カプセル化
    => 影響範囲が明確。必要分だけ確認
    カプセル化

    View Slide

  28. エンジニア的にいうと
    モジュールで分けます

    View Slide

  29. 影響範囲が制限されている
    だから、変更しやすい

    View Slide

  30. ファイルの種類ごとに管理
    仕様書
    責務が分かれている
    仕様書の見直しが必要な場合、
    仕様書ディレクトリを確認すればいい。

    View Slide

  31. 責務が分かれていると
    必要な箇所だけ編集できる

    View Slide

  32. 何が無関係か明確である

    View Slide

  33. 新規メンバーも着手しやすい

    View Slide

  34. ファイルの種類ごとに管理
    提案書 仕様書 ワイヤー アイコン
    プロジェクトごとにファイル管理する
    プロジェクトA
    提案書 仕様書 ワイヤー アイコン
    プロジェクトB
    用途ごとにまとめる 用途ごとにまとめる
    カプセル化
    => 影響範囲が明確。必要分だけ確認
    カプセル化

    View Slide

  35. 大多数の会社で同じですよね?

    View Slide

  36. では、コードはどうですか?

    View Slide

  37. ファイルの種類ごとに管理
    提案書 仕様書 ワイヤー アイコン
    MVCとDDDもこれと同じ
    DDD
    アーキテクチャ構成
    => 複雑になると混乱
    MVC
    PDF Excel Word img
    MVC
    => 担当箇所が明確

    View Slide

  38. つまり、
    フレームワークの機能ではなく、
    サービスの機能に合わせるべき。

    View Slide

  39. 機能の仕様がわかりやすい

    View Slide

  40. 別にそこまでしなくても
    いいんじゃない?

    View Slide

  41. 問題です。

    View Slide

  42. あなたのプロジェクトの仕様は
    どこにまとまっていますか?
    (※コードにおいて)

    View Slide

  43. パッと答えられなかった場合は、
    新規メンバーも困る可能性が高い

    View Slide

  44. DDDでは、
    Domain層に仕様を書く

    View Slide

  45. Presentation層
    Application層
    Domain層
    Infrastructure
    DDDの構成
    Controller, Request, ViewModel, Resource
    ApplicationService, Command
    DomainService, DomainModel, ValueObject
    Repository, Factory
    画面などに関わる部分
    CRUDなど機械的に必要な処理
    仕様に関すること
    AWSやDBなど機械に依存する箇所

    View Slide

  46. Controller
    Serivce
    Repository

    View Slide

  47. Controller
    ApplicationSerivce DomainSerivce
    Repository
    サービス層を二つにわける

    View Slide

  48. ApplicationSerivce DomainSerivce
    プログラムに必須 仕様に関すること
    CRUD publish()

    View Slide

  49. アプリの仕様は
    DomainServiceをまずみる

    View Slide

  50. Domain層
    DomainService:サービスの仕様
    DomainModel:オブジェクトの仕様
    ValueObject:カラムの仕様
    省略

    View Slide

  51. 注意点
    Domain層は必須ではない。
    複雑な仕様になったら、つくる

    View Slide

  52. レイヤー重視型 モジュール重視型

    View Slide

  53. レイヤー重視型
    レイヤーごとに機能のディレクト
    リが存在する

    View Slide

  54. 機能単位にモジュール分け
    モジュール内にレイヤードア
    ーキテクチャを採用する
    モジュール重視型

    View Slide

  55. 本質
    可読性を上げて、仕様がわかる
    責務がわかれている

    View Slide

  56. 注意点
    DDDを目的にしない。
    仕様がわかるコードが本質

    View Slide