今回は第4章まで。

第4章の要約

章のタイトルは「ドメインを隔離する」。

レイヤアーキテクチャによってドメインをその他のレイヤと分離する話が書かれています。また、その対極にあるものとして『利口なUI「アンチパターン」』というものが書かれていました。

レイヤアーキテクチャによるドメインの隔離

DDDではドメイン(レイヤ)をレイヤアーキテクチャにおけるその他のレイヤと分離しておく必要があり、これを達成できていなければ、DDDを行うことができないと書いてあります。

ドメインを中心にして設計を回すのがDDDのはずなので、UIとドメインロジックが一体化していたらドメインロジックの変更が困難だったりするのは大体明らかなところなので、そうかなという感じでした。

後半の章でいかにしてドメインを隔離しておくかということが書かれているらしい。（14、15章）

一方で、『利口なUI「アンチパターン」』に関しては、「あー、あるあるｗ」って感じで読みました。いわゆるMVCのModelもViewもControllerも密結合していて、UIの変更も、ドメインロジックの変更もすべてUI・ロジック双方に影響が出るような状況になっているタイプですね。

とりあえず作って終わりなプロトタイププロジェクトのようなものだと全然アリなのですが、何度も何度も繰り返し変更や追加がやってくるようなときには避けたほうがいいパターンだと認識してます（というのは本にも書いてありますね）。

この辺はMVCとかMVVMみたいな考えが役に立ちそうです。

結局のところ、チーム内の知識を高めていかないと、この辺りを避けて通って行くのが辛いというのは本にも書かれていました。チームとして、まずこの『利口なUI「アンチパターン」』が問題なのだという共通認識を作るのは重要なのかなと思いました。

DDDって実際にうまく回すには苦労しそうな点がたくさんありそうですね。「チームでDDDを行うための前提条件になる共通して理解しておくべき事」みたいなものもまとめておいたほうがいいのかもしれないと感じてます。始めてからでは遅いこと、とか、始めてからでもいいので理解しておいたほうがいいこととか。。。