現場で役立つシステム設計の原則のデータソース層とドメインモデルのつなぎこみに感動した
会社の同僚と読み合わせをしているのだけど、面白い本。 Java(というかSpringBoot)を使って、ドメイン駆動設計の考えに従って変更に強いアプリケーションを設計・実装していく方法がまとめられている。
レイヤードアーキテクチャとドメインモデル
増田さんは以下のような3層 + ドメインモデルの構造を示している。
(わかりやすい絵)
が、読んでいると実際にはPresentation層、Presntation層と結びついたApplication層、Application内部の小さな業務ロジックを担当するApplication層、ドメインモデル、ドメインモデルの一部としてのDatasource層、実際にSQLやAPIで情報を取得したり登録したりするDatasource層、くらいには層が分かれているねという理解になった。
(わかりやすい絵)
こういう暗黙の了解とか言い換えはそこそこ本著に入ってる気がした。
Datasource層とDBのコミュニケーションどうするの?
レイヤードアーキテクチャの章で感動したのは、データソース層とDBのコミュニケーション方法。 本著では、アプリケーションのシステム的構成と業務ロジックを「レイヤードアーキテクチャ」と「ドメインモデル」に分離しようとしているが、読み進めていて「いやそれはわかるけど、結局データソースとつながないといけないじゃん」と思っていた。
そしたらサンプルコードと共に解説されていた。
DataSourceのInterfaceはドメインとして定義して、それを実装する @Repository
アノテーションがついたDatasource層を用意する。
Datasource層は内部でORマッパーを持っていて、そいつがDBとコミュニケーションして、結果をドメインモデルに詰めて返してくれる。
たしかにこれなら、Datasource層にアクセスしたらあたかもドメインが取得できているように振る舞える。
言いたいことはわかるけどどうやるの?と、言葉にできないレベルでモヤモヤしていたことの実装例を見られてスッキリした。