-
-
Save suzuki-hoge/551b57c947b15140a015937e7b644ddf to your computer and use it in GitHub Desktop.
Contracts Between Bounded Contexts
- コンテキスト間で DTO を共有することを Contracts って言ってるの？
- 例えばこんなのが DDD 界隈にはあるよ
Shared Kernel Relationship
-
two contexts share some common domain design
- チームの強調必須
Customer / Supplier (or Consumer Driven) Relationship
-
the downstream context defines the contract that they want the upstream context to provide
- ドメインは独立して育てられる
Conformist Relationship
-
the opposite of consumer driven
- 今回のお題でいうと商品カタログの仕様とかを受け入れるあたり
Workflows Within a Bounded Context
+-- bounded context --+
+-+ +-+
| |
Command --------> Public Workflow --------> Events
| |
| -> Internal workflow -> |
| |
+-------------------------+
-
the input to a workflow is always the data assosiated with a command
-
and the output is always a set of event to communacate to other contexts
- けど billing context に対しては customer/supplier relationship なので、
OrderPlacedイベントではなくてBillableOrderPlacedイベントを新たに考えないといけないよ
component は物理構成、context はドメイン構成
c4 は component 構成の話
c4 のどの形で component と context を対応づけるかで、名前があるよ -> monolithic / soa
Avoid Domain Events Within a Bounded Context
bounded context 内の workflow は直列に繋げよう
layer を workflow で縦断するのではなくて、workflow の中を layer に分割しよう
layer は onion architecture で
（hexagonal architecture とかあるらしいけど、絵だけぱっと見た感じだと onion の方が細かい？（程度しか見てない））
- https://www.oreilly.com/library/view/microservices-with-clojure/9781788622240/assets/a57ba838-439c-4c24-b931-0f44864199c7.jpg
- http://www.duncannisbet.co.uk/wp-content/uploads/2012/08/project-tesselation1.png
di については 9 章で触れるよ？
一切の入出力を Domain layer で禁止したら、依存性の逆転ってしたくなる？
Keep I/O at the Edges
入出力は onion の一番外側でやろう
テストしやすいし汚れづらいよ
persistence ignorance （永続性非依存）とも合致するよ
永続化については 12 章で触れるよ
CHapter 4 Understanding Types
algebraic type system って何... 代数...??
代数データ型 ( haskell の data ) の特殊例として直和型と直積型と列挙型とレコード構文があるよ
- 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 の間とかになるのかな
Chapter 1 Introducing Domain-Drivin Design
Understanding the Domain Through Business Events
Chapter 3 A Functional Architecture
introduction
Communicationg Between Bounded Contexts
OrderPlacedとOrderDTOは用途や詳細な作りは違っていて、あくまでコンテキスト間連携専用のものってこと？