それどころか、「考えるには遅すぎ」と思っており、ずっと前に「やる」時が来たので、彼らは「万歳」と叫ぶバリケードに突進し、山に無駄なコードを大量に与えます。 他の極端な場合と同様に、このアプローチは良いものにはつながりません。 しかし、他の多くの場合と同様に、設計とアーキテクチャに十分な注意を払う場合、それらが最前線に置かれるのではなく、適切な抽象化を識別し、顧客の競合する要件の妥協点を見つけるために使用される中間オプションがあります。
クラス設計、モジュールアーキテクチャ、またはアプリケーションのさまざまな層の責任に関しては、結束と結合の概念が設計で決定的な役割を果たします。 デザインパターンの「父」であるクリストファー・アレクサンダーは、システムを分解する際の主なタスクは次の2つの条件を満たすことであると書いています：（1）コンポーネント内部の接続を最大化（ 高い内部接着 、緊密な内部凝集）および（2）コンポーネント間の接続を最小化（低外部結合）。
注
記事「デザインパターン」で、デザインパターンのようなユニークな概念の出現の歴史について詳しく読むことができます 。 サクセスストーリー 。
ボブ・マーティンといくつかの他の有名なパーソナリティのおかげで、SOLIDなどの兵器庫に原理が登場しました。これにより、システムの設計が上記の基本原理を満たしているかどうかをより正確に（またはおそらくより正式に）判断できます。 しかし、私は通常、「重砲」に移る前に、そのような原則の形でより単純なアプローチを使用します。 次の質問を自問します。「このクラスの主要機能を単体テストでカバーするのはどれほど現実的ですか？」答えがイエスの場合、指定されたクラスはおそらく他のクラスとの結合度が高く 、 接続 性が 低いでしょう。 単体テストの純粋に理論的な記述でさえ不可能な場合、クラスの責任は理解できないため、相互に無関係なフィールドとメソッドの束が含まれており、他の20個のエンティティに依存しているので、設計に明らかに問題があります。
図1-そして、この奇跡をテストする方法は？ しかし、実際の生活では、数倍の接続が存在する可能性があります。
ヒント
クラスの「テスト容易性」の原則を、適切なクラス設計の「リトマス試験」として使用します。 テストコードを1行も書かなくても（無駄ではありますが！）、90％のケースでこの質問に答えることで、デザインがすべて「良い」か「悪い」かを理解するのに役立ちます。
アプリケーションまたはモジュールのアーキテクチャに関しては、「テスト容易性」を品質基準にすることはできません。 もちろん、サブシステム全体の統合テストを作成できますが、それらのアーキテクチャの妥当性に関する有用な情報はほとんど提供されない可能性があります。
分散アプリケーションを構築するためのプラットフォームの選択、UIフレームワークまたはデータアクセスレイヤーのアーキテクチャの選択などのアーキテクチャの問題を解決する場合、「今の決定が間違っている場合はどうなりますか？」または「一般的に、今すぐ最終決定を下しますか？」
抽象化とカプセル化は依然として私たちの親友であり、それらは個々のクラスだけでなく、モジュール全体またはアプリケーション層に完全に適用できます。 WCFの使用は可能な限り通信層で非表示にする必要があります。UIフレームワークはすべての基本クラスから突出してはならず、データアクセス層のアーキテクチャはアプリケーションのビジネスクラスに制限を課すべきではありません。 もちろん、「 リーキーな抽象化の法則 」によれば、それでも定期的に不必要な詳細がアプリケーションの他のレイヤーに到達しますが、少なくともそれらを制限する必要があります。
優れたアーキテクチャは、細部まで考え抜くべきではありません。 優れたアーキテクチャは、アプリケーションの一部で発生するアーキテクチャ上のエラーが、論理的に無関係な異なるモジュールをどれだけ壊すかを理解するために十分に考慮されるべきです。
ヒント
テストケースがクラスの設計品質の「リトマス試験」であった場合、その「柔軟性」はアーキテクチャ品質の試験と見なすことができます。 「現在のアーキテクチャソリューションが間違っていると判明した場合はどうなりますか？」、「この場合、変更されるモジュールの数は？」を自問してください。 可能な場合はいつでも、建築上の決定を「断固とした」ものにしてはならず、建築上の誤りの結果は合理的に制限されるべきです。
トピックからの逸脱。 ボブマーティンによるクリーンアーキテクチャ
建築の実際的な見方の重要性については、かなり多くのことが書かれています。 有名な著書のGrady Butchは、さまざまなレベルでの抽象化とカプセル化の重要性について繰り返し述べています。 著書「ソフトウェアアーキテクトのための97のエチュード」では、多くの著者が「石のソリューションを削減する」ことの危険性と、アーキテクチャの問題における柔軟性に対するシンプルさの利点についてしばしば語っています。
最後に知られた作家の一人である建築のテーマは、ボブ・マーティンによって提起されました。 彼のプレゼンテーションの1つと、アーキテクチャに関する彼の投稿の1つで、ボブは次のように書いています。... 優れたアーキテクチャにより、重要な決定をポジショニングできます ... 優れたアーキテクチャは、未承認の決定の数を最大化します。
もちろん、 すべてのアーキテクチャ上の決定を延期できるという古いボブとは完全には同意しませんが、優れたアーキテクチャによってそれらの多くを延期できることに同意します。 そして、ここでは、これらの決定のタイミングだけでなく、その後の修正のコストの問題もあります。
注
私が上で言及したボブ・マーティンのプレゼンテーションは ここ にあり ます 、短いビデオ、この問題の議論は ここにあります 。 そして、同じトピックに関するいくつかのボブの投稿があります： Clean Architecture と Screaming Architecture です。
おわりに
上記の原則を「銀の弾丸」と見なさないよう読者に強くお勧めします。「銀の弾丸」は、「完璧な設計」または「完璧なアーキテクチャ」を得る方法の質問への答えを保証するものです。 このような質問はギャップを示すだけで、正しい道筋を示すことはできません。頭の中で警告灯を発し、クラス設計またはアーキテクチャ上の決定のより徹底的な分析を促すだけです。