Last active
August 7, 2019 02:39
-
-
Save suzuki-hoge/551b57c947b15140a015937e7b644ddf to your computer and use it in GitHub Desktop.
Domain Modeling Made Functional
イベントの方向と供給者とかは別の話
連携方法を決めたりするだけ
10. working with domain errors
ドメインエラーとそれ以外をわけよう
ドメインエラーは業務の単位で分けよう
在庫切れ -> ドメインエキスパートとフローを考える
住所検証システムが落ちてて検証できない -> また別のフローを考える
先日のマイクロサービスアーキテクチャででた機能低下の話と同じ？
全部落とさないで、別の方法で業務を継続できるのが望ましいのかな
アマゾンはカートシステムが落ちたら電話で受け付ける機能が有効になる、みたいな話
全てのエラーを設計時に掘り下げることはしないが、ドメインエラーかどうかは判断しよう
ドメインエラーなら列挙型に追加したりしよう
インフラエラーがドメインエラーになるかはケースバイケース
↑ 機能低下の話に繋がるのかな
あとは僕らでも特典がつけられなくても受付はやるみたいなケースもあるし
僕らは今は domain / panic, infra ( runtime ) みたいになってるな
例外（フロー）は必ずしもレイヤーで決まらない
uc で決まる
量販店だと即時だけど月末（まで）処理なら翌営業日、とか
そう考えると、エラーマッピングは api の上ではなくて api と service の間とかになるのかな
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
integrity: システムの堅牢さ
consistency: 業務の正しさ