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

オニオンアーキテクチャは、Domain Modelを中心に置き、技術詳細を外側に配置する設計です。

中心へ向けて依存する

UI / Infrastructure
        ↓
Application Service
        ↓
Domain Model

外側は内側を参照できますが、Domain ModelはApplication、DB、Web Frameworkを参照しません。この外側から内側への依存方向が中心ルールです。

業務ルールはDomain Model、取得・操作・保存の流れはApplication Serviceが担当します。

外部機能を使う方法

DomainやApplicationが保存を必要としても、特定ORMへ直接依存しません。内側にinterfaceを置き、外側が実装します。

interface OrderRepository {
  save(order: Order): Promise<void>;
}

class ConfirmOrder {
  constructor(private readonly orders: OrderRepository) {}

  async execute(order: Order) {
    order.confirm();
    await this.orders.save(order);
  }
}

Repository実装は外側でSQLやORMを扱います。Domainを守ることと、すべてをDomainへ入れることは別です。HTTP形式などは外側へ置きます。

適用を考える場面

• UIやDBよりDomain Modelを長く保ちたい
• 外部技術と切り離して業務ルールをテストしたい

単純なCRUDへ多くの層を追加すると、変換だけのコードが増えます。Domain Modelが薄い場合は単純な構成から始めます。

まとめ

• Domain Modelを中心へ置く
• コードの依存は外側から内側へ向ける
• Infrastructureは内側のinterfaceを実装する
• 業務ルールが薄い場所へ機械的に適用しない

接点の設計はヘキサゴナルアーキテクチャ、業務モデルはドメイン駆動設計（DDD）を参照してください。

参考リソース

• Jeffrey Palermo: The Onion Architecture

×

PR

×

PR