強いて言えば「集約どう実装するのかな、を考える」な話
•
6 j'aime•8,350 vues
アーキ部#13で使ったスライドです。 サンプルコードはこちらです。 https://github.com/kawasima/revisiting-domain-model
Recommandé
Contenu connexe
Tendances
Tendances (20)
Plus de Yoshitaka Kawashima
Plus de Yoshitaka Kawashima (20)
強いて言えば「集約どう実装するのかな、を考える」な話
- 3. CartにCartItemを追加する Add Cart Add Cart Add Cart 1 1 1 { “productId”: “mikan”, “quantity”: 1 } API Endpoint AddCartItemUseCase { “userId”: “kawasima”, “productId”: “mikan”, “quantity”: 1 }
- 4. ユースケースシナリオ 1. ユーザのカートが存在することを確認する。 2. productIdが実在する商品かつ販売中の商品であることを確認する。 2a. 販売中でない場合 2a1. その旨をユーザに通知して終了 3. カートに商品と数量を追加する 3a. 既にカートの中に同一の商品があれば数量を足し合わせる 3a カート内の商品の数量が100を超える場合 その旨をユーザに通知して終了 4. カートの内容を保存する
- 6. カート カートアイテム スタジアム 座席 列 番号 座席ランク 商品ID 数量 1 * ユースケース: あるカートアイテム の数量を変更する ユースケース: ある座席のランクを 変更する 制約: 同一ランクの座席数上限はス タジアム毎に決まりがある 制約: カート全体に入れることがで きる商品数量は100個まで 1 1..* ※10万席あるスタジアムもある A B
- 11. DDDトリレンマ: それぞれの選択に潜む悪魔 純粋性+完全性 純粋性+性能 完全性+性能 理想論の悪魔 👿 「純粋かつ完全なるドメイン …美しい」 ただし、遅くて使い物にならないけどな アンチドメインモデル貧血症 の悪魔 👿 「業務ロジックを発見し、濃いドメインモデルができたで〜」 こんな簡単なものに、こんな複雑な仕掛けが必要なの ? テスタビリティの悪魔 👿 「ドメイン層がピュアでテストしやすぅ〜」 ドメイン層スッカスカでテストが簡単に書けても、ユースケースからテスト通 さんと、ほとんど品質保証の意味をなさない。 どれも追求しすぎると、悪魔に取り憑かれる
- 15. (ドメインサービスの乱用による)ドメイン貧血症 class User { public exists(user: User): bool { // 重複チェック } } class UserService { public exists(user: User): bool { // 重複チェック } } Userに自分自身の存在確認メソッドを持た せるのは不自然。 なので、そういう場合にだけドメインサービ スを作るといいよ。 ドメインサービスの乱用は、ドメインモデル 貧血症を招くのでほどほどに … 『ドメイン駆動設計入門』より
- 16. どこに定義するかより、同じでないものを区別することが先決では? 内包されている「複雑さ」(異なる概念)を型で表現するのが重要 重複しているかもし れないユーザ 重複していないことが 保証されているユーザ 両者は別の概念 (なぜなら定義される 振る舞いが異なる) // ユーザの重複チェック ; 「重複しているかもしれないユーザ」にしか適用されない type existsUser = MaybeDuplicatedUser -> UniqueUser // ユーザの登録; 「重複していないことが保証されているユーザ」にしか適用されない type registerUser = UniqueUser -> RegisteredUser Parse don’t validate
- 17. Parse don’t validate https://sporto.github.io/elm-patterns/basic/parse-dont-validate.html Origin: https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/ type alias UserInput = { name: Maybe String , age: Maby Int } isValidUser : UserInput -> Bool このようなバリデータだけが用意されていると、UserInput型のデータはバリデートが済 んでも、invalidな値を保持している可能性がある。 実際に、これが元で過去いくつもの脆弱性が発生している。 http://langsec.org/papers/langsec-cwes-secdev2016.pdf
- 18. type alias UserInput = { name: Maybe String , age: Maby Int } type alias ValidUser = { name: String , age: Int } validateUser : UserInput -> Result String ValidUser バリデート済みであることを型によって保証する。 なので、バリデートはBooleanを返すのではなく、バリデーション済みの型にParseして返す
- 19. Type Safety Back and Forth https://www.parsonsmatt.org/2017/10/11/type_safety_back_and_forth.html 失敗可能性を後ろへ 失敗可能性を前へ (こっちの方がいいよね、という話) 入力を型によって制約保証す る。
- 20. Domain Modeling Made Functional https://www.slideshare.net/ScottWlaschin/domain-modeling-made-functional-devternity-2022
- 23. まとめ ● トリレンマにしたがい完全+純粋、純粋+性能、完全+性能な手段が考えら れる。 ● 1つのやり方に執着しすぎると、悪魔に取り憑かれるので注意しよう。 ● そもそもドメインにまつわる「複雑さ」は明らかにできているのか?