オニオンアーキテクチャ とは？

中心をいくつかの層が囲む形で説明するからだよ。中心には、注文や料金など業務の状態と振る舞いを表すドメインモデルを置く。外側には、画面やデータ保存などの具体的な実装を置くんだ。層の数は、どのアプリでも同じではないよ。

区切るだけでなく、ソースコードが何を参照するかを決めるんだ。業務ルールが特定のDB操作に直接依存していると、保存方法の変更が業務のコードにも広がりやすい。オニオンでは、外側が内側に依存し、内側は外側の具体的な技術を参照しないようにするよ。

たとえば内側に「注文を保存する」というインターフェースを置き、外側にその実装を用意するよ。実行時には、その実装を使えるように組み立てる。DBそのものがプログラムに依存するという意味ではなく、保存を担当する外側のコードが、内側の取り決めを実装するんだ。

外側の変更を中心へ広げにくくする設計であって、変更が必ずゼロになる保証ではないよ。保存形式や要件が変われば、検討やテストも必要。ただ、業務ルールを外部の実装から分けておくと、中心の振る舞いをDBなしで確認しやすくなるんだ。

構造を増やす負担と、将来の変更への効果を考えよう。提唱者のJeffrey Palermoは、2008年の記事で、長く使う業務アプリや複雑な振る舞いを持つアプリを想定しているよ。六角形やクリーンアーキテクチャとも共通する考え方はあるけれど、名前だけで全部同じ構造と覚える必要はないんだ。