Weitere ähnliche Inhalte
Ähnlich wie 抽象的な教えを試行錯誤しながら解釈した DDD の実践レポート (11)
抽象的な教えを試行錯誤しながら解釈した DDD の実践レポート
- 2. 2012 04 新卒入社 ど素人
1年くらい多重度をフランス語だと思ってた(→タジュード)
社会人歴の半分くらいは php でフロントエンド
後半の半分くらいは DDD をやっている
ここ1年くらいはテックリードみたいなことも
ScalaMatsuri とか Haskell Day に行ったりします
自己紹介
- 34. 1. Domain 層から Application 層や
Infrastructure 層への依存を断つ
2. ドメインが知る他のドメインを減らす
3. ドメイン間に線を引く時は、変更頻度が低
い方に向けて線を引く
やったこと
- 38. 1. Domain 層から Application 層や Infrastructure 層への依存
を断つ
→ ドメイン外の都合に振り回されない
2. ドメインが知る他のドメインを減らす
→ ドメインがコンパクトになる
3. ドメイン間に線を引く時は、変更頻度が低い方に向けて
線を引く
→ 修正箇所が減る
結果
- 41. モデリング結果が ER 図になるってよくあると思うんだけ
ど、これも Domain 層 → Infrastructure 層の依存と本質は
同じだと思う
ドメインとテーブルは同じペースで育たないって考えると
理解するヒントになるかな、と思っている
例えばエディタでクラスの分割したあと、データ移行でテ
ーブルの分割もセットでしない
変更する頻度や理由が違うものは、分けておくと良さそう
理解(余談:モデルと ER 図)
- 48. 今の DDD の理解は
Haskell 経験からの思
いつきと独学でしかな
いので、ちゃんと学び
たい
ちょっとずつ読み進め
てる、新たな発見が待
ち遠しい
FP での DDD を試してみたい
https://www.amazon.co.jp/Domain-Modeling-Made-Functional-Domain-Driven-ebook/dp/B07B44BPFB
- 49. 巨大 SQL は保守できないし Domain 層にならない
かといって更新と同じドメインクラスを無策に流用
すると、性能が悪いとか、変なドメインになったり
する
参照は更新と別で設計してみる様にし始めた
ドメインクラスに参照ルールをどの程度どうやって
書くか、性能とのトレードオフはどう考えるのか
参照って更新とは別な難しさがある
Hinweis der Redaktion
- 折角なので url をはっつけておきます、slideshare から見に行ってみてください
ぜひいいねしてね!
- お題や解答例自体は本題ではないので軽く流します
- 多少 is未成年() とかはありますね
あとは大体 getValue() があるのと、配送というよくわからない四角があります
- あと、リポジトリには手元の変数を全部そのまま渡してるだけ
実際はもっと膨大
- じゃあ次どうするか
- 今度は同じお題で動詞をハイライトします
- 名詞の時は絵を描きましたが、まだ日本語で整理します
- 絵は細かくなってしまったので詳細は割愛しますが、申込内容が受付内容(もしくはエラー)を return する様になってます
- この時点で自分の中では全部が一気に繋がり始めた気がします。
さらに次どうするか!
- ここからは今までと違って失敗ではなくてやったことをお話します
- 先ほどの動詞の抽出をして作った絵の、一部を抜粋してます
未成年は申し込めないという仕様は変わっていないのに、…
ドメイン ”に” 向かって線を引いているので、ドメイン “から” エラーメッセージはわからなくなった -> エラーメッセージがどう変わろうと、ドメインには関係ない
- 聞き馴染みない方もいらっしゃるかも知れませんが、依存性逆転の原則というのを使いました
- 赤地の部分が差分です
- (時間次第)
ビジネスエラー ユーザの操作によって起こる、応答する、冪等性がある
システムエラー ユーザの操作は関係ない、中断する、冪等性がない
- なんでかって言うと、