オニオンアーキテクチャ - ドメインを中心に置く設計

オニオンアーキテクチャとは、ドメインモデルを中心に置き、その外側をアプリケーションサービスやインフラで包む設計思想です。

一言でいうと

オニオンアーキテクチャは、業務ルールを玉ねぎの中心に置き、外側の技術詳細から守る設計です。

中心に近いほど変わりにくく、外側に行くほど技術的で変わりやすいものを置きます。

層の構成

中心のドメインは、外側の層に依存しません。外側が内側を使います。

クリーンアーキテクチャとの関係

オニオンアーキテクチャとクリーンアーキテクチャはかなり近い考え方です。

どちらも「内側は外側を知らない」という点が重要です。

処理の流れ

注文処理を例にします。

DBの保存方法が変わっても、注文可能かどうかのルールは変わりません。

なぜドメインを中心に置くのか

アプリケーションで長く残るのは、技術より業務ルールです。フレームワーク、DB、UIは数年で変わることがありますが、「注文には支払いが必要」「在庫がなければ出荷できない」といったルールは長く残ります。

ドメインを中心に置くと、変更の優先順位が見えやすくなります。

よくある誤解

ドメイン層は単なるデータ型でよい

ドメインモデルがデータだけになると、業務ルールがApplication層やControllerに流れ出します。エンティティやValue Objectには、守るべき不変条件や振る舞いを置きます。

Repository実装をドメインに置いてよい

ドメインがDB実装を知ると、中心が外側に依存してしまいます。ドメイン側にはインターフェース、インフラ側には実装を置くのが基本です。

すべての処理をドメインに入れる

メール送信、トランザクション制御、ログ出力などは技術的な関心です。ドメインには業務判断を置きます。

導入チェックリスト

• ドメインモデルに業務ルールがあるか
• ドメインがDBやHTTPの型を知らないか
• Application層がユースケースの流れを表しているか
• Infrastructure層に技術詳細が閉じているか
• テストでドメインだけを検証できるか

まとめ

オニオンアーキテクチャは、ドメインを中心に置いて、技術的な変更から業務ルールを守る設計です。

業務ルールが複雑なアプリほど、中心に何を置くかが保守性を左右します。

参考リソース

• Jeffrey Palermo: The Onion Architecture
• Microsoft: Clean architecture with ASP.NET Core
• Martin Fowler: Domain Model

関連記事

• ドメイン駆動設計（DDD）
• クリーンアーキテクチャ
• レイヤードアーキテクチャ

×

PR

×

PR