前回の記事
【ミライトデザイン社内勉強会#12】「IDDD本から理解するドメイン駆動設計」輪読会~第3章「コンテキストマップ」~ - Qiita
実践DDD本 第4章「アーキテクチャ」 ～レイヤからヘキサゴナルへ～：CodeZine（コードジン）
ヘキサゴナルアーキテクチャのポート、アダプタは具体的にどんな実装になるのか知りたい
- ポートがインターフェースでアダプタが具象クラス
- 例えば、DBに登録する処理で、ポートとなるインターフェースを定義しておき、アダプタとなる具象クラスをモッククラスと実際にDBに登録するクラスとで差し替えることでテストなんかもしやすくなる
- コンセントで例えると穴がポートでプラグがアダプター
- インターフェースを定義していたらヘキサゴナルアーキテクチャ？
- そういうわけでもない
- ヘキサゴナルアーキテクチャーはポートとアプリケーションの層を分けたアーキテクチャ
- 技術的な部分とアプリケーションを分離して、技術的な部分を差し替え可能にする
- クリーンアーキテクチャもヘキサゴナルアーキテクチャの一種
- クリーンアーキテクチャの外側の話をしているのがヘキサゴナルアーキテクチャ、ヘキサゴナルアーキテクチャのアプリケーションの内側の話をしているのがオニオンアーキテクチャ、ヘキサゴナルアーキテクチャとオニオンアーキテクチャをたすとクリーンアーキテクチャ。みたいなイメージ。
SOAを導入する = 境界づけられたコンテキストをそれぞれ独立したシステムになるように実装しようって話？
システムを「1つのデカいシステム」と捉えるのではなく「それぞれの機能を提供する部品（サービス）の集まり」と見なす考え方
- SOAの考え方を意識すると、ヘキサゴナルアーキテクチャでサービス作る時にいい設計ができるよって話
- ここではおそらくSAOでやらなきゃいけないっていうより、紹介程度な説明
境界づけられたコンテキストごとにヘキサゴナルアーキテクチャや他のアーキテクチャで実装されていて、それぞれが独立したシステムになっているのが理想ってこと？
- そう。
- 境界づけられたコンテキストごとに独立したアプリケーションになるイメージ
ical（一般的なカレンダー形式）のような汎用的なメディアタイプを使用することが推奨されています。と書いてあるけど、どういう意味？
- https://codezine.jp/article/detail/9922?p=3
- メディアタイプ - Wikipedia
- 公開用の独自モデルを設計 = 独自モデルをjsonで返す
- 汎用的なメディアタイプを使用する = imgaeとかで返す
- コアドメインをそのまま公開する = ドメインのオブジェクトを返すとか？？
- Restより前の技術の話をしている気がする
- 今ではapi叩いてjsonで返って来るのが当たり前みたいになってるからここの話はイメージが付きづらいのかも
CQRSで「コマンドモデル用データストア」と「クエリモデル用データストア」 を用意してデータソース分離するような設計ってイベントソーシングで実装したいとき以外にもすることはあるの？
- CQRSはデータソースは分離している。
- データソース分離しないとメリットとしてはCQSと同じ
- CQRSの方はコマンドとクエリを完全に分離するので、データソースも分離してある
- CQRSが解決したいのは、書き込み前提で正規化されたデータを読み込むのが辛いので書き込みと読み込みでデータソースを分けようってこと
- 書き込みのために正規化されたテーブルを読み込むと読み込みのたびに毎回joinとかをする必要がある
- 読み込み用のテーブルを作っておくと読み込むたびにjoinする必要がない
- データソースを分離しないとCQRSのメリットは活かせないと思う
- クエリ用のデータソースはコマンド用のデータソースと同期する必要がある
- イベントソーシングはコマンド用のモデルの書き込みはイベントの保存のみを行っている
- 一般的なアプリケーションは書き込まれた瞬間に読み込み側に反映する必要があるのでちょっとめんどくさい処理とかが必要になる
イベントソーシングでイベントストアに保存されるイベントは具体的にはどんなデータ形式で保存されているの？
- noSqlとか
- イベントのデータがクエリ用のデータと同じようにRDBに保存されているとは限らない
- CRADのイメージを1回捨てないとCQRSやイベントソーシングの考えを理解するのは難しいかも
- イベントソーシングはそれだけで1つ勉強会が開けるくらいボリュームがある話なので今回は割愛
次回
【ミライトデザイン社内勉強会#14】「IDDD本から理解するドメイン駆動設計」輪読会~第5章「エンティティ」~ - Qiita