階層化アーキテクチャから DDD へ。私の移住とモノリスの切断の経験

今日はバックエンド アプリケーションのアーキテクチャについて説明し、プロジェクトを構築する 2 つの一般的な方法、オニオンと DDD を比較します。最初のアプローチに対する 2 番目のアプローチの利点と、プロジェクトをヘキサゴナル アーキテクチャに移行した私の最近の経験についてお話します。このテキストは、すでに階層化アーキテクチャを使用していて、さらに詳しく知りたい人 (たとえば、マイクロサービスの使用を開始する人) を対象としています。

レイヤードアーキテクチャから始めましょう。レイヤード (オニオン アーキテクチャとも呼ばれる) は、アプリケーション全体を複数のレイヤーに分割するアーキテクチャです。各層には独自の機能と明確な目的があります。たとえば、データベースとの対話: このような層には、データベースと対話するための機能のみが含まれるべきであり、他には何も含まれない必要があります。クライアントやその他の機能との対話は行わないでください。

多くの場合、階層型アーキテクチャでは、バックエンドに 3 つの主要な層があります: ストレージとの対話用、アプリケーション ロジック、および代表的な層です。

これは典型的な 3 層アーキテクチャであり、すべてが非常に単純です。リクエストはすべてのレイヤーを通過し、最終的な形式 (ストレージ内のリクエスト) を取得し、応答はクライアントにとって便利な形式 (JSON、XML など) に変換されて戻ります。

私は、すべてのプロジェクトと参加しているスタートアップ企業で、かなり長い間このアーキテクチャを使用してきました。小規模なプロジェクトでは、このアプローチは実際に機能し、問題は発生しませんが、大規模なプロジェクトでは混乱が始まります。

レイヤード アーキテクチャの主な原則の 1 つは、他のレイヤーをまったく変更する必要がないように、任意のレイヤーを同様のレイヤーに置き換えることができることです。しかし実際には、プロジェクトに登場するエンティティが増えるほど、プロジェクトに準拠することが難しくなります。

最初は依存関係が多すぎるため、それらを制御することがますます困難になります。これは、モノリスが無視されていることを意味します (結局のところ、onion はモノリシック アーキテクチャです)。負荷が正しく分散されず、アプリケーションに過負荷が発生しています。さらに、レイヤーが混在し始め、アプリケーション ロジックを分離することがますます困難になります。アプリケーションの拡張はますます困難になり、依存関係によりデバッグは地獄になり、開発は大幅に遅くなります。火に油を注ぐことは、開発者の能力を制限する厳密なアーキテクチャ パターンです。このテキストを読んでいるあなたは、おそらくすでにこれに遭遇しているでしょう。私たちのプロジェクトでも同じ状況が発生しました。

このような状況では、モノリスを切り離し、別のアーキテクチャに切り替え、より自由なパターンを導入する必要があることは明らかです。私たちは DDD を選択しました。それは明らかな解決策のように思えました。 DDD (ドメイン駆動設計、ヘキサゴナル アーキテクチャ) は、抽象化に基づいて構築されたマイクロサービス (モノリシックとしても使用できます) アーキテクチャです。レイヤード アーキテクチャを扱った経験しかない場合は、大まかな例として、同じ 3 層アーキテクチャを想像できます。ストレージとの対話のレイヤーの代わりに、一般にすべてのテクノロジとの対話のレイヤーがあり、また、抽象化を備えた別のレイヤー。通常、DDD では抽象化が主なものです。これらの抽象化、補助ツールおよびデモンストレーション エンティティ (テンプレート、図) はアプリケーションから分離されており、その結果、アーキテクチャは次のようになります。

層状アーキテクチャと比較した六角形アーキテクチャの主な利点は、拡張性です。依存関係が少ないため、新しい機能、新しいパラメーター、新しい関数を実装するのがはるかに簡単です。

最初、この構造は私にとってまったく非論理的であるように思えましたが、DDD に切り替える過程で、インフラストラクチャがアプリケーションの最下位層からも完全に削除されたため、記述がはるかに簡単になったことに気づきました。依存関係が少なくなりました。各組織に対して、ある種の不合理な救済と突然の行動の自由さえありました。このアプローチは、レイヤード アーキテクチャよりもさらに論理的であるように私には思えます。

ただし、プロジェクト内に 2 ～ 3 個のエンティティがある場合、そのようなアーキテクチャは意味をなさないことに注意してください。DDD は主に、多数の依存関係を持つアプリケーションのマイクロサービス アーキテクチャとして使用されます。 2 ～ 3 つのエンティティを含む小さなペット プロジェクト。場所によっては、単純な線形アーキテクチャでも十分です。そして一般に、学ぶために実験することにした場合を除き、そのようにさまざまなテクノロジーや手法を不必要に使用することは悪い習慣です。

追伸そして、TGC に夢中になる必要があります: https://t.me/dmkjfss

以上が階層化アーキテクチャから DDD へ。私の移住とモノリスの切断の経験の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。