仕事で業務向けのWebアプリケーション開発をしています。その中でもいろいろな問題がやはりあるのですが、特に大きな問題だなと思えることがあります。エンハンスや保守改修が続くと、もうなにがなんだったか分からなくなってしまうことです。私はもう20代でもなくて、記憶力が衰えてきているということもあるのですが、問題はそこではないでしょう。むしろ、個人の記憶力が頼りになってしまうというのはおかしいことです。しかし、それが現実だということです。
仕事ではどうしてもこの現実から脱却できないということがあります。正直なところ、モダンな開発スタイルを取り入れている現場の雰囲気は分かりません。私が長いこと携わっている現場がそうではないからです。優先するのはWBS上の進捗と、変更するコードをいかに小さく限定するかということです。今かけるコストを最小にする、ということが最優先の現場はそれなりにあるのではないかなと思っています。ですから新しい枠組みを得るということができない訳です。
.. a large amount of business logic .. may exist on the client but more likely it exists on either pieces of paper in a manual or in the heads of the people using the system.
- CQRS Documents by Greg Young
だからこそですが、よくできていないという実情はよく分かっているつもりです（笑）。先にも書きましたが、取りわけ業務の知識がシステムの形として残らないということはかなりまずいことだと思っています。そんなわけで、ドメイン駆動設計やCQRSという設計思想には魅力を感じます。
書いてみました！
読み物だけでドメイン駆動設計やCQRSというものを理解していくことは難しいと思いましたので、簡易な演習プログラムを書いてみました。仕事の中で実践的に書いているわけではないので、オレオレになっているところがそれなりにあると思います。やさしくご指摘ください（笑）。
.. a team should be focused on what the use case really is.
- CQRS Documents by Greg Young
今回はやることを限定して目的を絞りました。コマンドとクエリを分割する、それだけです。イベントソーシングやリアクティブプログラミングはしません（まだあまり理解もできていないですし）。それでもアプリケーションが得ることのできるメリットは大きいと思います。ソースコードがやりたいことの意図を表現して、それが形として残るからです。
CQRSについて補足しておくと、CQRSはイベントソーシングが必須ではない。CQRSっぽい実装はすぐにでも初められる。
— Satoshi Matsushita (@satoshi_m8a) February 1, 2016
Repositoryを介さないで、直接DAOから、Read Modelを構築してそのまま返すのもあり。#ScalaMatsuri
何もかもをいきなり入れ替えようとするのではなく、できる範囲のことをやる、というアプローチは現実的ですごくよいと思います。また、小さく始めること、車輪の再開発をすることは、そのことを理解するには最善の方法だと思っています。
次回は、
ドメイン駆動設計やヘキサゴナル・アーキテクチャ、CQRSについてオーバービューしたいと思います。