-
-
Save suzuki-hoge/551b57c947b15140a015937e7b644ddf to your computer and use it in GitHub Desktop.
suzuki-hoge
commented
Mar 25, 2019
- integrity: value object や entity ( agregate? ) の組み立て不正
- consistency: ある entity が存在するべきなのにしないような、データ不整
- invariant: 発注数は 1 - 1000 等の、不変性
- Smart constructors - HaskellWiki
a useful guideline is “only update one aggregate per transaction.”
A classic example is transferring money between two accounts, where one account increases and the other decreases.
コンテキストをまたぐ集約の整合性をとる場合、当然依存させたりはしない
メッセージででもやりとりして、失敗したら詫びるなり補正するなりする
全部のエラーを実装するよりはるかにコストが低い
同一コンテキストの場合でも、トランザクションは集約ごとに切った方が良い
ただし送金の様な業務的に捉えてトランザクションが１つの場合（減額と増額）は一緒のトランザクションにした方が良い
consistency: 一貫性
integrity: 完全性
integrity: システムの堅牢さ
consistency: 業務の正しさ
イベントの方向と供給者とかは別の話
連携方法を決めたりするだけ
10. working with domain errors
ドメインエラーとそれ以外をわけよう
ドメインエラーは業務の単位で分けよう
在庫切れ -> ドメインエキスパートとフローを考える
住所検証システムが落ちてて検証できない -> また別のフローを考える
先日のマイクロサービスアーキテクチャででた機能低下の話と同じ？
全部落とさないで、別の方法で業務を継続できるのが望ましいのかな
アマゾンはカートシステムが落ちたら電話で受け付ける機能が有効になる、みたいな話
全てのエラーを設計時に掘り下げることはしないが、ドメインエラーかどうかは判断しよう
ドメインエラーなら列挙型に追加したりしよう
インフラエラーがドメインエラーになるかはケースバイケース
↑ 機能低下の話に繋がるのかな
あとは僕らでも特典がつけられなくても受付はやるみたいなケースもあるし
僕らは今は domain / panic, infra ( runtime ) みたいになってるな
例外（フロー）は必ずしもレイヤーで決まらない
uc で決まる
量販店だと即時だけど月末（まで）処理なら翌営業日、とか
そう考えると、エラーマッピングは api の上ではなくて api と service の間とかになるのかな