楽水

人々の創造が自由に表現できる舞台づくり

未分類

ドメイン駆動設計×ヘキサゴナルアーキテクチャ×契約による設計

投稿日:


ここでは、ドメイン駆動設計ヘキサゴナルアーキテクチャ契約による設計の考え方を適用して開発する方法について説明します。
次の図は、ドメイン駆動設計、ヘキサゴナルアーキテクチャ、契約による設計の考え方を適用したアプリケーションシステムの構造を表した図です。



次の順で説明します。

  1. ヘキサゴナルアーキテクチャ
  2. ビジネスロジック

ヘキサゴナルアーキテクチャ

次の図は、ヘキサゴナルアーキテクチャの構造を表した図です。



ヘキサゴナルアーキテクチャは、次の要素で構成されます。

  • ドメイン層
    • ドメインオブジェクト
      ドメインとは、開発対象となる業務領域のことです。
      ドメインオブジェクトとは、ドメインを構成する業務要素を表すオブジェクトで、集約、エンティティ、値オブジェクトから構成されます。
      ドメインオブジェクトのドメイン知識がアプリケーション層にが流出しないように注意します。
      アプリケーション層のアプリケーションサービスがドメイン知識を持つと、アプリケーションサービスとドメインオブジェクトの結合度が上がり、ドメインオブジェクトのモジュール性、再利用性が下がります。

      • エンティティ
        同一性(IDを持つ)と連続性(状態が変化する:mutable)を持つオブジェクト。
        参照オブジェクトともいいます。
      • 値オブジェクト
        事物の性質を表現するもので、等価性(同じオブジェクトは等価である)と不変性(状態を変えない:immutable)を持つオブジェクトのことです。
      • 集約
        ドメインオブジェクトのライフサイクルの単位のことです。
        集約の中核を担うエンティティのことを集約ルートといいます。
    • ドメインサービス
      ドメインに存在する概念の中には、1つの機能が単体で存在していて、エンティティや値オブジェクトなどのクラスのメソッドに属さない場合があります。
      そのような場合、その機能をドメインサービスという状態を持たない(statelessな)オブジェクトとして分類します。
    • リポジトリ
      集約の生存期間中、それを一時的にデータベース上に保管・問い合わせするための役割がリポジトリです。
      リポジトリは、DAO(Data Access Object)のようにデータをアクセスする機能ではなく、オブジェクトを保管する機能を抽象化したもので、メモリ上にあるコレクションを扱うように操作することができます。
    • ファクトリ
      集約の複雑な生成過程をカプセル化する役割がファクトリです。
  • アプリケーション層
    アプリケーションサービス
    アプリケーションサービスは、ドメインオブジェクトの直接のクライアントで、ユースケースのシナリオを実現するためにドメインオブジェクトのメソッドを調整するだけの役割を担います。
  • アダプタ層
    アダプタとは、アプリケーションシステムの入出力を接続し、アプリケーションのインターフェースに変換する役割のことです。

ビジネスロジック

ここでは、アプリケーションシステムが実現すべくビジネスロジックを次のように分けて説明します。

  1. ドメインロジック
    ドメインオブジェクトが実現すべくビジネスロジック。
  2. アプリケーションロジック
    アプリケーションサービスが実現すべくビジネスロジック。

ドメインロジック

ここでは、ドメインオブジェクトが実現すべくドメインロジックを、契約による設計の、事前条件、事後条件、不変条件という観点で説明します。

  • 事前条件
    ドメインオブジェクトの各メソッドを呼び出す側(アプリケーションサービス)が満たすべき条件のことです。
  • 事後条件
    ドメインオブジェクトが各メソッドを実行した後、満たすべき条件のことです。
  • 不変条件
    ドメインオブジェクト全体が常に満たすべき条件のことです。
    これは、集約のメソッドを通じて、特定の集約インスタンスの整合性を保持するための条件になります。
    例えば、注意番号には必ず値が設定されている必要があるなど、ある特定の注文オブジェクトに閉じた整合性の保証は、ドメインロジックの不変条件になります。

アプリケーションロジック

ここでは、アプリケーションサービスが実現すべくアプリケーションロジックを、契約による設計の、事前条件、事後条件、不変条件という観点で説明します。

  • 事前条件
    アプリケーションサービスの各メソッドを呼び出す側(アダプタ)が満たすべき条件のことです。
  • 事後条件
    アプリケーションサービスが各メソッドを実行した後、満たすべき条件のことです。
  • 不変条件
    アプリケーションシステム全体が常に満たすべき条件のことです。
    ユースケース(アプリケーションサービスのメソッド)を通じて、複数の集約種類間のトランザクション整合性や、複数の集約インスタンス全体のトランザクション整合性を保持するための条件になります。
    例えば、注文の状態と在庫の状態の間の整合性の保証、注文番号は一意でなければならないなど、リポジトリを介したすべての注文オブジェクト間の整合性の保証はアプリケーションロジックの不変条件になります。

-未分類

執筆者:

関連記事

アプリケーションアーキテクチャの設計方法

今回は、アプリケーションアーキテクチャをどう設計するのか説明します。 アプリケーションアーキテクチャは、エンタープライズアーキテクチャの一要素で、データアーキテクチャやビジネスアーキテクチャ

テクノロジーアーキテクチャの設計方法

今回は、テクノロジーアーキテクチャをどう設計するのか説明します。 テクノロジーアーキテクチャは、エンタープライズアーキテクチャの一要素で、データやアプリケーションを支えるIT基盤やコミュニケーション基 …

生成AIと創るマイクロサービス

先日、OpenAI社から ChatGPT-5 がリリースされました。 特に、コーディング能力が上がったという話なので、今回、GhatGPT-5と共創してマイクロサービスを開発してみました。 そこで、今 …

変化に強いシステムを創る

ここでは、環境の変化に柔軟に適応できるシステムを創るポイントについて以下の観点で説明します。 変化に強いシステムが求められる背景 変化に強いシステムを創るための3つのポイント 変化に強い情報システム …

制約理論(TOC: Theory of Constraints)とは

ここでは、制約理論について、次の観点で説明します。 制約理論とは 制約理論の5つのステップ 制約理論とは 制約理論(TOC: Theory of Constraints)とは、1984年にエリヤフ・ゴ …