Clean ArchitectureとCQRSは、いまや.NETの記事のほとんどに登場します。しかし、どういう場合に見合い、どういう場合に重荷にしかならないのかを書いた記事は多くありません。本稿では両者を費用の観点から見ます。得られるものと、支払うものです。
Clean Architectureが解決すること
中心にある考えは短い一文です。業務ルールは、データベースにも、フレームワークにも、画面にも依存してはならない。依存の向きは外から内へ、一方向だけ。
.NETの構成では、次の四層に分けるのが一般的です。
- Domain — エンティティ、定数、値の型。外部を一切参照しません。
- Application — 業務の流れ、コマンドとクエリ、外部要素の抽象。
- Infrastructure — データアクセス、メール送信、ファイル保存、外部サービス呼び出し。
- WebApi — 入口、認証、経路制御、依存関係の登録。
実際の利点は、保存方式やメール送信ライブラリを替えても、業務ルールを持つ部分に手を入れずに済むことです。同じくらい重要なのは、データベースを立てずに業務ルールを試験できることです。
支払う対価
ただの昼食はありません。目に見える費用が三つあります。
- 同じ作業に対してファイルが増える。単純な機能でも、コマンド、ハンドラ、入力検証、変換定義が要ります。行の読み書きしかしないアプリでは、純粋な上乗せです。
- 新しく入った人には追いにくい。命名とフォルダ構成を一貫させて補います。美しい構成図より、守られている規約のほうが効きます。
- 中途半端になりやすい。アプリケーション層からデータベースを直接叩く箇所がひとつあるだけで、構造全体の利点は崩れます。しかも、すぐには誰も気づきません。
CQRS — 参照系と更新系を分ける
CQRSは「データベースを二つ用意すること」と誤解されがちです。最も実務的な水準では、こう言えるだけです。データを変える命令は一方の道を通り、データを読む問い合わせはもう一方の道を通り、両者はモデルを共有しない。
分ける理由は次のとおりです。
- 更新系にはルール検査、監査記録、壊れないトランザクションが要る。
- 参照系には、画面が必要とするデータだけを、往復を最小にして返すことが要る。多くの場合、変更追跡も不要です。
同じモデルを共有すると、参照系は不要な項目まで引きずり、更新系は表示都合で膨らみます。分ければ双方が簡単になります。
処理パイプライン — CQRSが最も報われる場所
すべての操作がひとつの中継点を通ると、繰り返しの処理をシステム全体で一度だけ書けます。
- 入力検証をハンドラ実行前に自動で通す。各所に書き直す必要がありません。
- 記録と所要時間の計測をすべての操作に対して行い、散在するコードなしに遅い箇所を見つける。
- 誤りの扱いを統一し、業務エラーが常に同じ形で画面側へ届く。
- トランザクションの開始と終了を一か所に置き、開発者の記憶に頼らない。
使うべきでない場合
寿命の短い小さなアプリ、マスタ管理が数画面、担当は一人か二人。この場合は軽い層構造で十分であり、そのほうが早く終わります。
本格的な構成に移る目安です。
- 数年使われ、保守担当が交代する見込みがある。
- 入力フォームだけでなく、実質的な業務ルールがある。
- 画面、モバイル、裏方処理、外部連携など、複数の入口が同じ業務処理を共有する。
ありがちな失敗
- エンティティが何でも入れる箱になる。表示のためだけの項目を業務モデルが持ち始めたら、境界がぼやけ始めています。
- ハンドラが別のハンドラを呼ぶ。共通部分は独立したサービスに切り出し、流れを上から下へ読める形に保ちます。
- 抽象が多すぎる。実装がひとつしかなく、試験の役にも立たないインターフェースは見直す価値があります。
- 単体試験しかない。最も誤りやすいのはデータ取得の部分で、そこは実際に動かして初めて問題が出ます。
まとめ
Clean ArchitectureとCQRSは規範ではなく、取引です。初期の冗長さを支払って、後から変えられる余地を買う。業務ルールが多く、変更が続き、寿命を年単位で数える企業システムでは、この取引はたいてい割に合います。数か月で役目を終える社内ツールでは合いません。
