考える場所

ココロとカラダ、思考する全部

CQRSの小さな演習(2) 設計の枠組み

ドメインモデル貧血症」や「利口なUI」と言われるアンチパターンがあるのは、そのパターンをやってしまいがちだからだと思います。そうでなければわざわざアンチパターンとして識別するような名前をもたなかったでしょう。データベースから取得したなんとかデータをサーブレットで全部処理してしまう、というような感じですね。よくあることです。

これはこれで、ちゃちゃっと作ってしまうには楽であるという面もあります。しかし、エンハンスや保守改修が続けばつらくなってくることもまた事実です。よほど何かの理由があるのでなければ、メンテナンスしやすいような設計をしておきたいものです。

ドメイン駆動設計

ドメイン駆動設計は、以前からあるさまざまな設計の考え方とやり方を、ドメインを理解しその理解をコードで表現することに焦点をあてて、解釈しなおしていること。
- 増田さんのツイート

というのを目にして、なるほどなと思いました。「たとえばこのような業務があったときに、オブジェクト指向的な設計をすればこうすることができるんじゃない」ということを言ったものです。技術的に新しい何かをするのではなくて、何をクラスとして切り分けてどのようなメソッド呼び出しをするべきか、というような。それは設計の指針というか、枠組みみたいなものです。

f:id:fukuchiharuki:20160228110338p:plain

DDDとは、ドメインに集中して、集約・エンティティ・値・サービス・仕様・イベントなどをきちんとモデリングしましょう、ということだと理解しています。さらに、そのためにユビキタス言語を使って継続的に会話するなど、開発の方法や体制を含めた考え方でもあります。

大きなメリットは知識が形として残ることだと思います。そもそもDDDでは、設計はすべからく、ユビキタス言語を使いながら知識をモデリングするべしと言っています。モデル駆動設計やオブジェクト指向設計と区別されるようなものではなく、それらをドメインに集中させたもの、と考えるのがよさそうです。ドメイン中心の設計思想であるとも言えます。

ヘキサゴナルアーキテクチャ

.. if the database is moved from a SQL database to a flat file or any other kind of database, the conversation across the API should not change.
- Alistair.Cockburn.us | Hexagonal architecture

ヘキサゴナルアーキテクチャは、アプリケーションを中心に据えて、インフラストラクチャをアダプターとして外側に配置するアプリケーション構造です。対比して考えると分かりやすいのがレイヤードアーキテクチャです。ヘキサゴナルアーキテクチャでは、たとえば、リポジトリの実装は外側にあります。アプリケーションはリポジトリのインタフェースを見ているだけなので、UTをするときににデータベースのアクセスをオンメモリの何かに置き換えることができます。

f:id:fukuchiharuki:20160228104805p:plain

これは依存関係をどのように認識することができるかという問題で、レイヤードアーキテクチャであってもそのように実装するものと考えていた、ということはあると思います。個人的にはドメインモデルはなにものにも依存しないということが絵として表現できているヘキサゴナルアーキテクチャの方が好きです。オニオンアーキテクチャというものもありますね。

メリットはテストのしやすさです。言い換えると、アプリケーションとインフラが疎結合になるということです。また、概念的にも実装的にもドメインオブジェクトを独立したものにするので、ドメイン中心の考え方をより確実にすることができるように思います。

CQRS

It is not possible to create an optimal solution for searching, reporting, and processing transactions utilizing a single model.
- CQRS Documents by Greg Young

CQRSでは、コマンドはコマンド処理をするところが、クエリはクエリ処理をするところが、という責務の分離をします。逆説的に言えば、画面表示するために取得したデータに入力した値をセットしてアップデート、をしないことです。コマンド処理をするということは、ドメインにおけるイベントを起こすことです。たとえば、住所をUPDATEする、とCRUDでデータ更新することを考えるのではなく、引っ越したまたは住所を修正した、というドメインの出来事が起きることを考えます。

f:id:fukuchiharuki:20160228104817p:plain

CRUDなデータ更新を考えるのではなく、ドメインのイベントを考えるというのはDDDそのものです。しかし、そこに画面表示するための都合を入れてしまうと、モデルがデータを出し入れする入れ物になってしまいます。ドメインのことをモデリングしながら同じものを画面表示に利用することはできない、とCQRSでは言っていて、コマンドとクエリの責務を分離するわけです。

CQRSのメリットはDDDのメリットがそのままです。CQRSをすることはDDDをするための前提だと思います。また、ドメインエキスパートをドメイン知識のモデリング(コマンド側)に集中させることができるので、適材適所に開発を分担しやすくなります。

まとめ

DDDはドメインの知識を形にする設計思想でした。ヘキサゴナルアーキテクチャは実行環境依存なインフラストラクチャを外側にしてドメインモデルを中心に据える構造でした。CQRSはコマンドとクエリの責務を分離してドメインモデルを純粋なものにする考え方でした。

現実の困難に鑑みて、DDDやヘキサゴナルアーキテクチャ、CQRSは、意識して実践する価値があると思います。DDDはこれで正解ということが難しいですが、ヘキサゴナルアーキテクチャやCQRSは形式として採り入れやすそうです。そうしたらもっとDDDができそうな気がしますね。

blog.fukuchiharuki.me

最初

blog.fukuchiharuki.me