- コンテキストマップをきちんと書く事でどこからどこまでが境界付けられたコンテキストなのかがわかる。
- 境界付けられたコンテキスト同士の関係もわかる
- パートナーシップ
- 密接に関係しててどっちかがこけたらもう片方もこける。片方をimproveしたりするときには足並み揃えないとダメ
- 共有カーネル
- コードとかjar自体を共有しちゃう。
- 顧客/供給者
- 上流/下流があるときに下流の都合に合わせて上流のインターフェース決めるやつ（BFFパターンとかがこれにあたりそう）
- 順応者
- 上流/下流があるときに下流が上流の決めたインターフェースにがんばって合わせないとダメなやつ（PMと受付アプリの関係）
- 腐敗防止層
- 下流クライアントが上流の都合に合わせなくていいように、上流のインターフェースから下流内部のドメインコードに適合させるためのアダプタを書くレイヤを作ることがある、それのこと
- 上が腐っているという意味ではなくて、上流のコンテキストの概念が下流に混入してしまわないようにするための層なので否定的な意味合いではない
- 公開ホストサービス
- 上流:下流が1:nみたいなやつ
- 公表された言語
- XMLスキーマだとかprotocol bufferだとか最近だったらjson schemaとかがそれにあたるっぽい。カスタムメディアタイプなど。この言語に従っている限りそのサービスはちゃんと動きますよを保証する。
- 別々の道
- 無関係にやっていく（はてなブックマークとはてなブログの関係。同じ汎用サブドメインを上流に持つことはある）
- 巨大な泥だんご
- 責務がボロボロになっても一枚岩でやる
- 巨大な泥だんごにメスを入れてちゃんとしようなどとは思わないことだ！
- コアドメインが下流になることが多い、びっくりするかもしれないけどよく考えるとあたりまえかも
- 上流と下流というのは依存関係の言い換えですねこれは
-
認証アクセスコンテキストとコラボレーションコンテキストの間は顧客/供給者でやっていくことにした。
- RPCやREST使うと同期的になってわかりやすいし容易なんだけど依存度が高まるしパフォーマンス上の問題も
- 独立性を高めるためには下流は下流に必要な情報だけどを下流のドメインの言葉で保持しておく、RESTとかMessageHubとかで上流の変化をどうにかして下流に取り込むと良い
- RESTベースでやるなら下流が上流に「どんなイベントがあった？」って聞きに行く形になる
-
コラボレーションコンテキストとプロジェクト管理コンテキストの場合
- 認証アクセスコンテキストは「常にユーザーが存在してること」を前提にしていいけど、プロジェクト管理コンテキストが、あるプロジェクトに対するディスカッションをアドオンとして提供して、なおかつそれがコラボレーションコンテキストの責務であるみたいな場合、議論を開始するときにはコラボレーションコンテキストにそのプロジェクトのフォーラム？はまだ存在しない。
- プロジェクト管理コンテキストで「議論を開始する」したらコラボレーションコンテキストにフォーラムとディスカッションを作成しないといけない
- イベント駆動アーキテクチャと結果整合性を利用すると独立性たかくしておける、しかし結果整合性だとありうる状態をたくさん管理しないといけない、そこちゃんとモデリングしましょう
- まあいろいろ見てきたけど詳細はもっとあとでやるわ
- とにかくコンテキストマップを書いて複数の境界付けられたコンテキストの関係をみんなで共有するといいよ
- なんらかのアーキテクチャ採用するときにはちゃんと合理的な理由をもって採用しようね
- ユースケースがわからない限り「最適なアーキテクチャ」は決まらないからまずはユースケースをきちんと分析することから始めるんだぞ
- LayeredArchitecture
- UIレイヤ
- アプリケーションレイヤ
- ドメインレイヤ
- インフラストラクチャレイヤ
- それぞれ上位が下位に依存する
- インフラストラクチャがドメインに依存するならドメインをInterfaceと実装にわければよい
- インフラストラクチャに依存するとテストとかいろいろ大変
- DIP使うといいね
- DIP使って実装への依存をなくしていくと、レイヤーの上下という概念なくなっていくよね
- 要するにDI使ってプレゼンテーション層を入れ替え可能にするってことだよなこれ
- サービス指向なんて言葉忘れたほうがいい
- ヘキサゴナルアーキテクチャを採用していれば、RESTとSOAP両方を提供するとかもできるので、サービスのありかたがひとつ増えれば境界付けられたコンテキストが同じだけ増えるなんてことは防げる
- RESTでドメインオブジェクトをそのままリソースとして公開したらアカンですよ
- リソースはもっと抽象度の高いものになるはず
- コマンドとクエリでアーキテクチャわけちゃう
- CとRで永続データさえわけちゃうことも
- ドメインイベントのやりとりを中心に考えて書く。
- ヘキサゴナルアーキテクチャを利用していれば、入出力層は自由に入れ替えられるはずなので、そこからイベントを入出力するようにしておくと相性が良い
- 長期プロセス
- ひとつのイベントを複数のサブシステムに投げる
- サブシステムは計算を進める
- サブシステムの計算の結果をイベントとして受け取る
- 全部受け取ったらそれを結果としてどこかに書き出したりする
- この状態管理をしてくれるくんを集約として書いておく
- Akkaと相性よさそう…？
- イベントソーシングするといろいろいいことがある
- 付録Aが最高なのでみんなちゃんと読むべし
- データファブリックにドメインオブジェクトをそのままシリアライズしてぶっこむ
- インピーダンスミスマッチなし！
- 各種アーキテクチャをサポートするための汎用技術として検討の価値のあるものである（ほんとか？）