面白かった。
 実践ドメイン駆動設計 |
僕とドメインモデル
1歩目
PoEAAとDDDを読んで。Transaction Scriptとかドメインモデル貧血症とかじゃなくてドメインモデルでアプリを作りたいなー。と思って。
エンティティ、値オブジェクト、集約、リポジトリ、ドメインサービス、アプリケーションサービス。
などとりあえず登場人物の名前を覚えるも、全くやり方が分からず。
2歩目
んで、ドメイン駆動(Jimmy Nilsson)を読んで。ちょっとトライ。
レイヤーアーキテクチャにDIで上下逆みたいな感じにしてみて、そこはなんとなく良さげに作れたかなーと思ったんだけど。
でも、結局リポジトリ周りがRDBに引っ張られてうまく設計できず。
3歩目
「DB用のEntityというものと、ドメインモデルのEntityは違うよ。」などアドバイスをもらって再度挑戦。
ふむ。DBの呪縛から少し解かれて自由な感じがしてきた。
でも結局DBの力に頼るところとかが出てきて。やっぱりDB寄りになってしまった。
4歩目
そして、実践ドメイン駆動設計を読みました。すごく良かった！
ので、いくつか、良いなぁと思ったところを書く。
実践ドメイン駆動設計を読んで
集約
1回のトランザクションで更新するのは1つの集約だけってのが、そうなのかー！って感じ。
集約はトランザクション整合性の境界と同義である
でも、そんなこと言っても、その更新によって色々周りも変えなきゃいけないじゃん。
って思ってたら。それを処理するのがドメインイベントってことで。
ドメインイベント
トランザクションで整合性を保つんじゃなくて、結果整合性を保つ。か。
なるほどなー。
よく考えたら、似たようなことをやったことあるかも。
って、僕のはそんなに整然としてなくて、言われてみて考えてみたら、そういうことがやりたかったんだわ、って気づいたぐらい。
そをイベント駆動のアーキテクチャとして、結構詳しく紹介してくれてて。なるほどなー。って感じ。
イベントストア
で、イベントストアのRestAPIとNotificationの話があって。
RestAPIだとリアルタイム連携はむずい。分かる分かるー。
NotificationってなるとRabbitMQとかで切り離すんかな。ふむふむ。
でもこんなん実装したらイベント多すぎてパニックにならんのかな？と思ったり。
いや、想像するより実際にやってみたら案外気にせずさばけるんじゃないのか？と思ったり。
面白そう。
リポジトリ
で、僕の苦手なリポジトリ。なんだけど。
コレクション指向のリポジトリの設計・実装の目標は、HashSetの特徴を兼ね備えた永続データストアを作ることになる。
で、あー。そういうことがやりたかったのか。と、ここにきてやっと、理解し始めた。
確かにそれって、オブジェクトとして扱えて、使う分には自由そうだなー。
でも結局僕は、永続指向のリポジトリの方を作りたいんだろうな、って。
ヘキサゴナルアーキテクチャ
レイヤーアーキテクチャの「上下」的な考えじゃなくて「内外」だよ。って考え方で。
結局、やってることはあんまり変わらないけど、捉え方が違うって印象。
確かにプレゼンテーション側や、インフラ側をドメインモデルから切り離して
内側だけを扱えたら、純粋なビジネスロジックとしてテストできて気持ちよさそう。
サンプルコード
色々サンプルコードが載ってるので、実際にアプリケーションサービスがどんなパラメータを受け取って
それを使ってどんな風にサービスを呼び出すか、とか、トランザクションをどうするか、とか
その辺の具体例があって勉強になりました。
追記: 境界づけられたコンテキスト
忘れてた！この本では最初に「境界づけられたコンテキスト」「コンテキストマップ」「腐敗防止層」とかの話をしてくれてて。
DDDじゃ後ろの方にある話なんだけど。これが良かった。
全体を最初に見てから詳細に入る、というやり方で読みやすかったのだ。
面白かった！
適当な自分プロジェクトを立ち上げて、DDDでどう進めるかってのを考えてみたいなと思った。
 エンタープライズアプリケーションアーキテクチャパターン |
 エリック・エヴァンスのドメイン駆動設計 |
 ドメイン駆動 |
