Zenn
😺

DDDと責務、Architecture..③DDDに関連するアーキテクチャ概要

2024/09/29に公開
DDD
OOP
クリーンアーキテクチャ
オニオンアーキテクチャ
tech

アーキテクチャと責務について

以前にDDDについて,DDDの概要を知るという記事と、
モデリング手法(集約とコンテキスト)について
を書きましたが、そこから進んで今日は
DDDに関連してるアーキテクチャについて、概要を書きたいと思います。

個人的に触っているのがオニオンアーキテクチャなので、
オニオン以外は実装してないという意味で、"概要"としました！

DDD概要復習

DDD復習

DDDはそもそも何を実現したいか?

→ ビジネスの本質(ドメイン)に基づいた、柔軟で保守性の高いシステムを構築すること

DDDで重要なポイントは?

  1. ドメインに基づく設計
    システムの中心はビジネスドメインの知識(ルールや概念)!

ドメイン: システムが解決するべきビジネス上の問題やニーズを明確にする役割
ex. ECサイトなら... 注文の管理,顧客管理,など

  1. ユビキタス言語
    ビジネス側と開発者側が同じ言葉（ユビキタス言語）を使ってコミュニケーションを取り
    同じ理解を共有することが重要。( + そしてそれをコードに落とすこと！)
  2. 境界づけられたコンテキスト
    ドメイン（業務領域）の意味や振る舞いが適用される範囲や境界のこと。
    特定の概念や用語が意味を持つ範囲
    ex.
  3. 集約
    一貫性を持って操作されるオブジェクトのグループ
  • なぜコンテキストが重要か？なぜコンテキストで分けるのか？
    → システムの複雑さを管理するため。
    → 同じ言葉でも使う場所で意味が異なるため、各コンテキスト内で    明確な意味を持たせる    ため。

DDDに関連するアーキテクチャについて

全部は書ききれないが概要を書きたいと思う。
そもそもだが、DDDで有名なエヴァンス本にもアーキテクチャについての言及は
詳細に書かれてはいないし、
クリーンアーキテクチャなどの本でDDDについて具体的な記述があるかといえばそうでもないです。

DDDの原則をサポート(実践)する設計パターンの一つとして、
クリーンアーキテクチャやオニオンアーキテクチャなど扱われることが多いが、
厳密に言えばこれらは必ずしもDDDの一部とも言えない...?
難しい!笑 一旦ここまでとして、、それぞれの理解をかいていく。

レイヤードアーキテクチャ

  • エヴァンス本で紹介されているアーキテクチャの一つ。
  • 起源でいうと、1990年代〜2000年代初期.
    PoEAAでの設計パターンがDDDの土台となり、そこからさらに発展したものでもある。

※ レイヤード: 階層化
この意味では、オニオンもcleanも階層化されたアーキテクチャだから根本としては一緒！
基本的な構造は同じだが、依存関係の管理や各層の役割に違いがある

  • 複数の層に分けて(階層化: レイヤー化)設計する方法であり、各層は特定の責務を持つ。
  • ビジネスロジック層の責務を分担するため、usecaseの実現する層とドメイン層で分けた

ここでの問題点は、ドメイン層がインフラ層に依存してしまうことだった。
(ドメインロジックが外部技術に依存してしまう)
= ドメインの実装や知識がインフラ層(DBなど)の実装に引っ張られてしまうことになる。

PoEAAで紹介されたパターン（リポジトリパターン、サービス層パターンなど）を
積極的に活用しつつ、よりビジネスロジックに注目した設計を仕出したのがDDDなのだ。

オニオンアーキテクチャ

  • Jeffrey Palermo氏により考案されたアーキテクチャパターン。登場は2008年。
    → 本ではなく、以下に記されている
    onion architecture Part1~4
  • DDDのレイヤードアーキテクチャから依存関係逆転の原則を用いてドメイン層とインフラ層の依存関係を逆転させたもの。

依存関係逆転の原則: Dependency Inversion Principle
SOLID原則の一つであり、上位モジュール（ビジネスロジック）が下位モジュール（インフラストラクチャ）に依存せず、抽象的なインターフェースを介して依存関係を逆転させる。

  • アプリケーション層（Usecase）と外側のインフラ層との間には明確な境界があり、アダプター（例: コントローラ）を通じて通信する。

  • Inside-outの設計
    → 外側の円にあるコンポーネント（例: データベース、UIなど）は内側（ドメインロジック）に依存するが、その逆は許されない。

  • レイヤー間に明確な責務の境界があり、各層が異なる役割を担うことで保守性が高まる。

  • ビジネスルールやドメインロジックはアプリケーションの中心に配置され、
    インフラストラクチャやフレームワークに依存しない設計がなされている。

ヘキサゴナルアーキテクチャ: hexagonal architecture(別名: Ports and Adaptersアーキテクチャ)

  • 実践DDDで紹介されているアーキテクチャ。登場: 2005年

  • 2005 年にAlistair Cockburn氏により考案されたアーキテクチャパターン
    → ヘキサゴナルアーキテクチャ提唱記事
    → cockburn 氏おすすめのヘキサゴナルアーキテクチャ学習サイト

  • ドメインロジックとインフラストラクチャの依存関係を逆転させ、システムの中心にビジネスロジック（ドメインロジック）を配置する。
    その周囲に「ポート」（インターフェース）と「アダプター」（実装）を配置する構造を持つ。

  • 「ポートとアダプター」というアプローチ

    • ポート: 外部システムやインフラ層とドメインロジックとの接続点
    • アダプター: そのポートを実装する役割を持つ。
      → ビジネスロジックを中心に設計し、それ以外のインフラ層や外部システムを交換可能な部品として扱う。

  • このアーキテクチャも同様、依存性逆転の原則（DIP） を遵守しており、外部システムがドメインに依存する。

クリーンアーキテクチャ: clean architecture

  • クリーンアーキテクチャは、登場は2012年頃。
    オニオンアーキテクチャやヘキサゴナルアーキテクチャ、その他のアーキテクチャの思想を統合し、
    概念を統一しようとしたもの    。
  • 基本的な考え方は、依存性逆転の原則（DIP）に基づき、システムの中心にビジネスロジック（ドメインロジック）を配置し、外部の技術に依存しない構造を作ること。
  • 特に「外部からの依存を内側に持ち込まない」ことに重点を置き、
    ビジネスロジックの純粋性とテストのしやすさを維持することを目的としています。

→ 記載Page: https://blog.cleancoder.com/uncle-bob/2011/11/22/Clean-Architecture.html
→ 参考：翻訳版　https://blog.tai2.net/the_clean_architecture.html

共通する基本的な考え方や特徴

  1. 依存性逆転の原則の適用: ビジネスロジックが外部技術に依存しない。
  2. ビジネスロジックを中心に設計し、外部技術がその周辺に位置付けられること。
  3. テストがしやすい構造を提供し、ユニットテストやインテグレーションテストが容易。
  4. 柔軟性と拡張性の意識があり優れていて、技術の進化や外部システムの変更に対応しやすい。
  5. レイヤーを明確に分離し、各レイヤーが責務を分担。

Discussion