Upgrade to Pro — share decks privately, control downloads, hide ads and more …

不味いDDDと美味しいDDD

 不味いDDDと美味しいDDD

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

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

これが本質です。

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

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

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

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

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

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

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

ぎゅう

September 22, 2022
Tweet

More Decks by ぎゅう

Other Decks in Marketing & SEO

Transcript

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

    View full-size slide

  2. どう思いますか?

    View full-size slide

  3. 本当でしょうか?

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  7. MVC vs DDD
    よくある議論

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  11. 良いDDD × 悪いDDD

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  14. 現実世界で考えよう

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  20. MVCはこれに近いです

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  23. これがMVCの問題です

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  41. 問題です。

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  46. Controller
    Serivce
    Repository

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide