モード1：4層構造
1.Userインタフェースは、ユーザインタフェース層（またはプレゼンテーション層）で、ユーザに情報を表示し、ユーザコマンドを解釈する責任があります。ここでは、ユーザーは必ずしも、別のコンピュータシステムへのユーザー・インターフェースを使用している人を参照することができます。
2.Applicationは、アプリケーション層のために、ソフトウェアの定義は、タスクを完了し、問題を解決するために、コマンドオブジェクトのフィールドの概念を表現します。この層は、ビジネスに大きな意義の仕事に責任がある、また、アプリケーション層、他のシステムと対話するために必要なチャンネルです。できるだけ簡単なようにアプリケーション層に、彼らはお互いに協力しそうという、ビジネスルールや知識が、唯一の次の層内の領域を対象と協調タスク、仕事の配分のためには含まれていません。これは、ビジネスの状況の状態を反映していないが、それは別の状態を持つことができ、ユーザーまたはプログラムのタスクの進行状況を表示します。
ビジネス概念、ビジネスルールとサービスのステータス情報を表現するための責任を負うドメイン層（または層モデル）用3.Domain、。保存業務の状態の詳細は、状態によって制御され、使用されているインフラストラクチャ層によって実行されるが、この層の経営状況を反映しているが。フィールド層は、ドメインモデルは、この層に位置しており、ソフトウェアのコアビジネスです。
アプリケーション層メッセージ配信、フィールド層を提供するための持続性機構、アセンブリ画面を描画するユーザーインターフェース層、等：4.Infrastructure層はベース層の一実施形態である、他の層に共通する技術的能力が提供されます。アーキテクチャフレームワークによって4つのレベルの間の対話モードをサポートも可能なインフラストラクチャ層。
モード2：5段
まず、3層アーキテクチャ（データ、コンテキストおよびInteractive）
データ層は、システムおよびこれらのオブジェクトのフィールドに設立されたオブジェクトと関係のライフサイクル管理上の層と重点分野概念間の関係を説明し、プログラマスタンドオブジェクトの観点で考えるシステムなので、理解しやすい「システムとは何か」という。
コンテキスト層：一つの層はできるだけ薄いです。コンテキストは、多くの場合、その役割の相互作用が一緒にビジネスロジックが可能に完了するので、ちょうど、右の役割を見つけ、あまりにもステートレス実現されています。しかし、シンプルが重要でないという意味ではありません、文脈層の表示は、ソフトウェアのビジネスプロセスは、エントリポイントとメインラインを提供理解する人です。
対話型層は、主に、モデリングの役割に反映され、それぞれの役割がの、複雑なビジネスロジックのコンテキストで実際の演奏では「システムは何をすべきか。」役割は、コンテキストとドメインオブジェクトに参加する行動モデリング、あるん。システムの挙動は、複雑かつ多様であるのでように、システムを安定化し、動作層を分離し、フィールド層モデルシステム、システムの挙動モデリングの役割に焦点を変化させる役割。この層は近いソフトウェア工学、オブジェクト指向設計の考え方の練習にクラスに基づいてより多くの視点では、システムの拡張性に焦点を当てる傾向があります。
二つは、5段
1.Userインタフェースは、主に、ユーザ入力などをユーザー繧プロファイルによって送信された要求を処理し、解析するために使用されるユーザインターフェイス層であり、情報は、アプリケーション層の界面に渡されます。
2.Application層は、マルチプロセス管理およびスケジューリングを担当するアプリケーション・レイヤ、マルチスレッド管理およびスケジューリング、保守計画およびマルチコルーチンサービスインスタンス状態モデルです。要求スケジューリングレベルユーザインターフェース層、処理のためにこのサービスに関連した層委託コンテキストコンテキストを受信した場合。
3. コンテキスト単位の文脈では、芸術は一緒にインタラクティブな役割は、ビジネスロジックを完了するように、適切な役割にドメインキャスト層オブジェクト、環境層です。
4.Domain層は、フィールドの層であり、ドメインモデルは、キャラクタオブジェクトの役割を明示的にモデル化をさらに含む、オブジェクト間の関係をモデル化の分野だけでなく、を含むように定義されています。
フレームワーク、永続機構、メッセージング、包装、一般的なアルゴリズムサードパーティライブラリなどのプログラミング、サービスプラットフォーム：5.Infrastructure層はベース層の一実施形態である、他の技術的機能のための共通の層が設けられています。
三つは6つのアーキテクチャ
1.Userインタフェースは、主にユーザによって要求て送信繧プロファイルを処理して、ユーザ入力などを解析するために使用されるユーザインターフェイス層であり、情報がインターフェース層スケジューラに渡されます。
2.Schedulerスケジューリング層は、マルチプロセス管理とスケジューリング、マルチスレッド管理やスケジューリング、メンテナンススケジュールおよびマルチコルーチンサービスインスタンスの状態モデルを担当しています。要求スケジューリングレベルユーザインターフェース層を受信した場合、この操作に関連する層委託トランザクションは、トランザクション処理です。
3. 取引トランザクション層、UEは、アタッチのような、ビジネス・プロセスに対応する非同期メッセージまたはトランザクションに同期メッセージ処理シーケンスを複数組み合わせて、ほとんどのシナリオで、そこ選択構造。トランザクションが失敗した場合は、その後すぐにロールバック。トランザクション層は、要求ディスパッチ層、処理層アクションデリゲートのコンテキストを受信した場合、使用は、多くの場合、アクションの層コンテキスト仕様（述語）の選択を伴っています。
同期メッセージ又は非同期メッセージを処理する動作単位に環境層4.Context、技術は一緒にインタラクティブな役割は、ビジネスロジックを完了するように、適切な役割にドメイン層キャストオブジェクト。環境仕様は、典型的には、ドメイン知識層によって判定条件を完了するために、即ち、層を含んでも実施しました。
5.Domain層は、フィールドの層であり、ドメインモデルは、キャラクタオブジェクトの役割を明示的にモデル化をさらに含む、オブジェクト間の関係をモデル化の分野だけでなく、を含むように定義されています。
フレームワーク、永続機構、メッセージング、包装、一般的なアルゴリズムサードパーティライブラリなどのプログラミング、サービスプラットフォーム：6.Infrastructure層はベース層の一実施形態である、他の技術的機能のための共通の層が設けられています。
モードIII：六角形のアーキテクチャ
異なるレイヤ間の依存関係を変更することによって改善の目的を達成する階層化アーキテクチャ、即ち依存性逆転原理（依存反転原理、DIP）を、改善するための一つの方法。
この定義によれば、DDDは、低レベルのコンポーネントのアーキテクチャは、高レベルのコンポーネントを提供するインターフェイスに依存しなければならない積層、すなわち、抽象的にハイレベル又はローレベルに依存するかどうか、全体の階層化アーキテクチャは、フラットをプッシュしているように見えます。我々はいくつかの対称性を追加したブルドーザー階層化アーキテクチャを、置く場合は、その六角形のアーキテクチャ、対称の建築様式の特徴のようなものがあるでしょう。アリスター・コバーン六角形のアーキテクチャは、異なる顧客はシステムと「平等」相互作用の仕方によって、このアーキテクチャでは、2005年に提案されています。新規のお客様は、それを必要としますか？それは問題ではありません。ちょうどライン上で理解APIのシステムに変換することができ、新たなクライアントアダプタの入力パラメータを追加します。一方、各特定の出力のために、新しいアダプタは、変換関数を完了するための責任があるがあります。
以下のように六角形のアーキテクチャは、ポートアダプタとして知られています：
各六角形の異なる側面は、ポート、入力ポートまたは処理、又は出力処理の種類を表します。各タイプの外部ために、対応するアダプタ、インテリアと相互作用する外部のアプリケーション層APIがあります。3つの顧客の要求は、アダプタDを使用する別のクライアント要求を同じ入力ポート（アダプタA、B及びC）に到着している上記の図 最初の3つの要求（例えばRabbitMQのような）AMQPプロトコルを用いて要求に続いて、HTTPプロトコル（ブラウザ、REST、およびSOAP、など）と仮定する。ポートと明確な定義はありませんが、それは非常に柔軟な概念です。いずれかの方法でポートを分割することが、クライアントの要求が到着したときに、対応するアダプタ入力変換があるはず、その後、ポートは有料を制御ので、アプリケーションの動作を起動するか、アプリケーションにイベントを送信します内部領域へ。
クライアント・アプリケーションは、ドメインモデルを使用して要求を処理するために、共通APIを介して要求を受信します。私たちは、アダプタが重合のアクセス以前に格納されたインスタンスにするか、新しい集計インスタンスの保存に使用され、永続的なアダプターとして見られているDDDの戦術は、リポジトリをデザインモデリング要素（リポジトリ）を達成することができます。アダプタE、F及びGショーに示すように、我々は、リレーショナルデータベース、ファイルベースのストレージ、分散キャッシュまたはメモリ・ストレージなど、異なる方法リポジトリで達成することができます。アプリケーションは、外の世界のフィールドイベントにメッセージを送信した場合、我々は、処理のためのアダプターHを使用します。アダプタを処理するメッセージ出力、及びアダプタAMQPメッセージ処理は、別のポートを使用する必要があり、従って、上記プロセスの受信メッセージです。
私たちは、実際のプロジェクト開発で、異なる層の成分を同時に開発することができます。ときに、特定のコンポーネントの機能は、すぐに開発を開始することができます。アセンブリの複数のユーザ、およびこれらのユーザーの異なる焦点ので、異なる複数のインタフェースを提供することが必要です。それと同時に、また、理解を深め、これらのユーザーは、数回は、関連するインターフェイスを再構成する火災があります。このように、複数のユーザーの構成部品は、多くの場合、潜在的に開発コンポーネントの効率が低下し、これらの問題を議論するためにアセンブリの開発者を見つけます。
機能部品は、安定的かつ効率的な機能を確保するために、開発機能に焦点を当てた後、我々は明らかに、それを開発者のコンポーネントを別の方法を置きます。ユーザインタフェースコンポーネントカスタムコンポーネント（ポート）、およびインターフェイスに基づく試験、及び進化インタフェースを書き込みます。場合クロスレイヤ統合テスト、成分現像剤又はその上にユーザーの再開発アダプタ。