Bob Martinの「Clean Architecture」は、すべてのアーキテクチャの経験則ですか、それともオプションの1つですか？

ボブ・マーティンおじさんのビデオ「きれいな建築の原則」のビデオのコンセプトが本当に気に入りました。しかし、このパターンは、その中心にある抽象ファクトリーパターンとビルダーパターンの組み合わせのようなものだと思います。

これは優れたプログラムを作成する1つの方法ですが、唯一の方法ではありません。

Railsとreactjsは、この種のクリーンなアーキテクチャを促進しない2つのフレームワークです。Railsは、ビジネスロジックがモデル（FatModelsおよびSkinnyControllers）内にあることを期待し、コンポーネント内で反応します。どちらのアプローチも、ビジネスロジックとフレームワークコードを密接に結合します。

私は3つの方法のいずれにおいても間違ったことを見つけません。いずれかを選択するのは判断の呼び出しです。

しかし、ビデオでは、クリーンなアーキテクチャにはビジネスロジックとフレームワークの明確な境界があるべきだと彼は示唆しています。フレームワークは、（ウェブ、アンドロイドなど）プラグインする必要があることをプラグインにでビジネスロジックへ。彼はビデオのレールをわずかにモックしています。

それでは、Bob Martinによる「クリーンアーキテクチャ」はすべてのアーキテクチャの経験則ですか、それともオプションの1つにすぎませんか。

「クリーンアーキテクチャ」は優れており、多くの利点がありますが、次のことに注意することが重要です。

• クリーンアーキテクチャの大部分は、ロバートC.マーティンによるブランド変更と関連アプローチの進化です。ジェフリーパレルモによるオニオンアーキテクチャ（2008）や、アリステアコックバーンなどによるヘキサゴナルアーキテクチャ（「ポートとアダプタ」）など（<2008）。

• 異なる問題には異なる要件があります。Clean Architectureおよび関連するアプローチにより、デカップリング、柔軟性、および依存関係の反転が最大11になりますが、シンプルさが犠牲になります。これは常に良いことではありません。

これらのアーキテクチャの前身は、Smalltalkの古典的なMVCパターンです。これにより、ユーザーインターフェイス（コントローラーとビュー）からモデルが解かれ、モデルがUIに依存しなくなります。MVP、MVVMなど、MVCには多くのバリエーションがあります。

より複雑なシステムには、ユーザーインターフェイスが1つだけではなく、複数のユーザーインターフェイスがある場合があります。多くのアプリは、Webアプリやモバイルアプリなど、任意のUIで使用できるREST APIを提供することを選択します。これにより、サーバー上のビジネスロジックがこれらのUIから分離されるため、サーバーはどの種類のアプリがそれにアクセスするかを気にしません。

通常、サーバーは依然としてデータベースやサードパーティプロバイダーなどのバックエンドサービスに依存しています。これはまったく問題なく、シンプルな階層型アーキテクチャにつながります。

六角形のアーキテクチャはさらに進んで、フロントエンドとバックエンドを区別しなくなります。外部システムは、入力（データソース）または出力になります。コアシステムは必要なインターフェイス（ポート）を定義し、外部システム用のアダプターを作成します。

強力なデカップリングのための古典的なアプローチの1つは、すべてのサービスが共有メッセージバスとの間でイベントを発行および消費するサービス指向アーキテクチャ（SOA）です。同様のアプローチが後にマイクロサービスによって普及しました。

これらのアプローチにはすべて、システムを単独でテストするのを簡単にするなどの利点があります（インターフェースとのすべての外部システムをモック実装に置き換えることにより）。ある種類のサービスに複数の実装を提供する（2番目の支払いプロセッサを追加する）、またはサービスの実装を交換する（たとえば、OracleデータベースからPostgreSQLに移動する、またはGoでPythonサービスを書き換えることにより） 。

しかし、これらのアーキテクチャはフェラーリのアーキテクチャです。高価であり、ほとんどの人はそれらを必要としません。Clean Architectureなどの柔軟性の追加には、複雑さが増します。多くのアプリケーション、特にCRUD webappsはその恩恵を受けません。テンプレートを使用してHTMLを生成するなど、変更される可能性のあるものを分離することは理にかなっています。バッキングデータベースなど、変更される可能性が低いものを分離することはあまり意味がありません。何が変わる可能性があるかは、コンテキストとビジネスニーズによって異なります。

フレームワークは、何が変わるのかを推測します。たとえば、Reactはコンポーネントの設計と動作が一緒に変化することを前提とする傾向があるため、それらを分離することは意味がありません。フレームワークを変更することを想定しているフレームワークはほとんどありません。そのため、フレームワークはある程度のロックインを示します。たとえば、（非常に意見のある）Active RecordパターンへのRailの依存により、データアクセス戦略を（多くの場合優れた）Repositoryパターンに変更することは困難になります。変更の期待がフレームワークと一致しない場合は、別のフレームワークを使用する方が良い場合があります。他の多くのWebフレームワークは、データアクセスに関する仮定を行いません。

私は、ボブ・マーティンおじさんのビデオ「きれいな建築の原理」のコンセプトが本当に気に入りました。しかし、このパターンは、その中心にある抽象ファクトリーとビルダーのパターンの組み合わせのようなものだと思います。

程遠い。

これを見ると：

オブジェクトグラフの設計を見ています。これにより、何が何を知っているかが決まります。このストーリーから欠けているのは、オブジェクトグラフがどのように構築されたかです。申し訳ありませんが、ここにはありません。建設についての言及はありません。

これらすべてを、抽象的なファクトリやビルダーなしで構築できます。私はそれをやったので知っています。私はそれらを避けるために着手しませんでした。私は彼らを愛しています。私はそれらを必要とすることがたまたまなかった。参照渡しを使用しました。依存性注入は、そのための凝った用語です。

実際、メインの図にあるすべてのものを作成できました。次に、1つのオブジェクトで1つのメソッドを呼び出すだけで、すべての処理が開始されます。

物を他のものに押し込む前に、物は存在しなければなりません。私はここでそれを調べて、このかわいい小さな図を与えました：

そして、あなたはそこを離れることなくすべてを構築できますmain()。

手続き構築コードの山を一口サイズの概念的なチャンクに分割したい場合は、ビルダーとファクトリーを使用することをお勧めします。しかし、クリーンアーキテクチャや他の流行語アーキテクチャには、あなたが行うことを要求するものは何もありません。だから、あなたが固執したいならmain()、結構です。ただ、慈悲を持ってください。

Bob Martinの「Clean Architecture」は、すべてのアーキテクチャの経験則ですか、それともオプションの1つですか？

Clean Architectureは、人々をブログや本に誘導するための流行語と考えています。そのブログと本は、人々を古いブログや古い本に誘導するために使われた古い名前を持つ、非常によく似た古いアーキテクチャの非常に良い説明を持っています。具体的には、タマネギとポートおよびアダプタ。どれもあなたが持っている唯一のアーキテクチャ上のオプションではありません。

ボブおじさんは、素晴らしいパブリックスピーカーであり作家でもあるので好きです。彼は私がそうでなければ持っていないものを考えさせてくれます。しかし、あなたがそれをあなたが宗教的な熱狂に変えて、すべてを彼のやり方でやらなければならないと主張するなら、あなたはすぐにドキュメントの更新が私のコードに到達できるようにすることに最も近いことがわかります。

流行語アーキテクチャは、周囲の世界が変化する間、永続化する必要のある長寿命のコードがある場合に役立ちます。それが輝くときです。コードと比較して世界が安定している場合、正当な理由もなく物事を派手にしています。

どんなに素晴らしいものであっても、それを入れることのできるコンテキストがあり、それはばかげています。申し訳ありませんが、これも特効薬ではありません。

しかし、ビデオでは、クリーンなアーキテクチャにはビジネスロジックとフレームワークの明確な境界があるべきだと彼は示唆していると感じています。フレームワーク（web、androidなど）は、ビジネスロジックにプラグインするプラグインである必要があります。彼はビデオのレールをわずかにモックしています。

あなたが正しい。彼はやる。ボブおじさんは、フレームワークをライブラリのように扱うことができると感じています。そして、彼らはできます。しかし、その決定でさえも何かを犠牲にします。

マーティン氏が保存しようとしているのは、あなたの汎用言語がまだ一般的な空間です。フレームワークをどこにでも広げると、それはあきらめます。それを行うと、言語をドメイン固有言語と呼ばれるものにモーフィングするパスに向かっています。HTMLはドメイン固有の言語です。それは非常にうまくいきますが、まったくできない他の仕事があります。

フレームワークによってニーズが予測されている限り、事態は非常にスムーズに進みます。ニーズを予測しておくと便利です。それはあなたを物事をシンプルに保つ箱に入れます。これを得るためにあなたがgivingめていることを理解してください。Springをどこにでも広めると、それをJavaの仕事として宣伝することはできなくなります。これはJava / Springの仕事です。RubyとRailsについても同じことが言えますが、Railsはずっと前にRubyの昼食を食べました。

ビデオを引用するには：

「SQLで差し込み印刷を行いたくありません。」

に続く：

「実際には、差し込み印刷全体であるSQLストアドプロシージャを見ました」

差し込み印刷のようなアーキテクチャは、多くの選択肢の1つにすぎません。

オプションではないのは、アーキテクチャが解決しようとしている問題です。

SQL差し込み印刷が他のソリューションと比較してどのような問題を引き起こすかを理解すれば、アーキテクチャの選択が通知され、「悪い」ソリューションを選択せざるを得ない場合でも、不足を認識して軽減できます。

よく考えられているという理由だけで建築スタイルに従うと、間違いを犯して同じ問題に遭遇する可能性が高くなります。

「クリーンアーキテクチャ」は間違いなく「唯一」の選択肢の1つです。私はそれがほとんどのプロジェクト、特にオブジェクト指向のプロジェクトにとって悪い選択肢の一つだと主張します。

以下は、ボブおじさんのクリーンアーキテクチャに関する記事の文ごとの分析で、上記の声明の理由があります。

オブジェクト指向の観点からのクリーンアーキテクチャ

クリーンアーキテクチャは、ソフトウェア開発組織が複雑なアプリケーションを構築する際にしばしば直面する多くの一般的な症状に対処するための一連の原則とパターンです。マーティン氏は、この分野での豊富な経験に基づいて症状と根本原因を特定し、これらの懸念を緩和するためのアーキテクチャの役割を明確にするために、本の中で非常に詳しく説明します。

ただし、これは経験則ではなく、すべての病気に対する万能薬でもありません。この本を読むと、彼が提唱する原則とパターン（およびそれに伴うトレードオフ）を適用する場合、いつ、いつ、どのように適用するかをよりよく理解できます。本を読んでいない場合は、不完全な情報に基づいて誤った仮定、申請、判断、および発言を行う可能性があります。