コンポーネントによりソリューションを構築する

一段落説明

中規模以上のアプリでは、モノリスは本当に良くありません - 1つの大きなソフトウェアに多くの依存関係を持たせることにより、推論が難しくなり、スパゲッティコードになってしまうことが多いからです。賢いアーキテクト — 獣を飼いならして「モジュール化」するのに十分なスキルを持った人 — であっても、設計には多大な精神的な努力を費やし、変更ごとに他の従属オブジェクトへの影響を慎重に評価する必要があります。究極の解決策は、小さなソフトウェアを開発することです: スタック全体が、他の人とファイルを共有しない自己完結型のコンポーネントに分割されており、それぞれが非常に少ないファイル (例えば、API、サービス、データアクセス、テストなど) で構成されているので、それらについての推論が非常に簡単になります。これを「マイクロサービス」アーキテクチャと呼ぶ人もいるかもしれませんが、マイクロサービスは従わなければならない仕様ではなく、一連の原則であることを理解することが重要です。多くの原則を採用して本格的なマイクロサービスアーキテクチャを構築することもできますし、いくつかの原則だけを採用することもできます。ソフトウェアの複雑さを低く抑えていれば、どちらも良いでしょう。最低限すべきことは、コンポーネント間に基本的な境界線を作り、プロジェクトのルートに各ビジネスコンポーネント用のフォルダを割り当て、それを自己完結型にすることです - 他のコンポーネントは、パブリックインタフェースまたは API を介してのみ、その機能を使用することができます。 これは、コンポーネントをシンプルに保ち、依存関係の地獄を回避し、アプリが成長すれば、将来的に本格的なマイクロサービスへの道を開くための基礎となります。

ブログ引用: "Scaling requires scaling of the entire application" (スケーリングにはアプリケーション全体のスケーリングが必要)

ブログ MartinFowler.com より

モノリシック・アプリケーションは成功を収めることができますが、人々はモノリシック・アプリケーションに不満を感じるようになってきています - 特に多くのアプリケーションがクラウドにデプロイされるようになってきているためです。変更サイクル同士は連動しています - アプリケーションのごく一部に変更を加えると、モノリス全体を再構築してデプロイする必要があります。時間が経つにつれて、良いモジュール構造を維持することが難しくなり、そのモジュール内の1つのモジュールだけに影響するように変更を維持することが難しくなります。スケーリングでは、アプリケーションの一部だけでなく、アプリケーション全体を拡張する必要があり、多くの場合、より多くのリソースを必要とします。

ブログ引用: "So what does the architecture of your application scream?" (では、アプリケーションのアーキテクチャは何を叫んでいるのでしょうか?)

ブログ uncle-bob より

...図書館の建築を眺めていると、あなたはおそらく壮大な入り口、図書館員のためのエリア、読書エリア、小さな会議室、そしてギャラリーの奥には図書館の本をすべて収納した棚があるのが見えるだろう。その建築は悲鳴を上げるだろう。図書館と。

では、アプリケーションのアーキテクチャはどんな悲鳴を上げているのでしょうか？ 最上位のディレクトリ構造と最上位のパッケージのソースファイルを見たとき、ヘルスケアシステム、会計システム、在庫管理システム などと叫んでいませんか？ それとも、次のように叫んでいるでしょうか。Rails、Spring/Hibernate、ASP ?

良い: 自己完結型のコンポーネントでソリューションを構築する

悪い: 技術的な役割ごとにファイルをグループ化