建築の匂いはありますか？

Webには、コードのにおいを参照し、リストするリソースが山ほどあります。しかし、建築の匂いに関する情報を見たことはありません。これはどこかで定義されていますか、利用可能なリストはありますか？アーキテクチャの欠陥、およびプロジェクトの速度、欠陥などへの影響について正式な調査が行われましたか？

編集：私は本当に答えのリストを探していませんでしたが、アーキテクチャに関する臭い（ウェブ上または本）のドキュメントを探していました。

• 多層アーキテクチャ レイヤオンレイヤオンレイヤオンレイヤ...がある場合、アプリケーションで私のポイントを確認できます。Over Layered Architectureと呼びます
• コードで迷子になるような方法での抽象化。
• 未来のアーキテクチャこれは、ソリューションが未来的すぎる場合に発生します。実際には、誰も新しい要件を予測できません。したがって、未来の実装のほとんどは、時間とリソースの無駄です。
• テクノロジー熱狂的なアーキテクチャアーキテクト は新しいテクノロジーを気に入っており、生産を開始しました。それが前に証明されたかどうか知らずに。
• オーバーキルアーキテクチャ単純な問題は、アーキテクチャのスキルとテクノロジーの指数関数的な要因によって解決されました。
• クラウドアーキテクチャ アーキテクチャは実際には接続されていないため、クラウドアーキテクチャと呼んでいます。これは、素晴らしいVisioの図です。

反対の完全な欠如も真実です。

トップ10ソフトウェアアーキテクチャミスのリンクを次に示します。

すべてが構成可能です。設計者が、彼のシステムは変更が不可能であるか、広範な設定可能性のために高度にカスタマイズ可能であるとあなたに言うとき、それはアーキテクチャの匂いです。

問題は、実際に構成する必要があると思われるものに対してのみ構成メカニズムを実際に提供できるが、アプリケーションが実際に使用されると、それでは十分ではないことです。次に、構成メカニズムが拡張および拡張され、最終的に内部プラットフォーム効果が得られます。

そして、あなたはソフトウェアの地獄にいます。

ORMによって設計されたデータベース！または、リレーショナルでなければならない非リレーショナルデータベースバックエンド。または、ビューを呼び出すビューを呼び出すビューを使用するように設計したデータベースは、ビューが遅すぎるだけでなく（データベースは最初からパフォーマンスのために設計する必要があります）、変更を加える必要がある場合、追跡するのは恐ろしいです（@AmirResaeiが言ったように抽象化を超えているため、これらすべてのレイヤーの最下部にある何かを修正する必要がある場合、コードに簡単に迷子になります。）

コードの匂いと建築の匂いはまったく同じです。最適でないアーキテクチャのために、コードは「臭い」を始めます。

トピックに関するリファクタリングに関するMartin Fowlerの独創的な本で、彼は一連のコードの匂いを提示し、システムからそれらをリファクタリングする方法を特定します。Joshua Kerievskyの「パターンへのリファクタリング」は、さまざまなコードの匂いを修正する特定のアーキテクチャパターンを提供することで、このアイデアをさらに強調しています（そして、それらを段階的にリファクタリングする方法）。

ほとんどのリファクタリングは、強化されたアーキテクチャを介して次善のコードを軽減するために行われます。自然に生まれた唯一の「建築の匂い」（泥のビッグボール以外）は、BDUF（Big Design Up Front）アーキテクチャであると主張することができます。コードの最初の行を書く前に必要なものすべてに対応しようとする場所。必要に応じて設計が行われるアジャイルソフトウェアプロジェクト（コードが設計として扱われる場合もあえて）では、そのアーキテクチャが有機的に成長します。

（多くの）カップリング -どんな形であれ-がアーキテクチャを匂わせます。結合すればするほど、匂いがします。

つまり、カップリングがまったくない場合、パフォーマンスの問題が発生することがよくあります。

私がいつも遭遇する具体的なアーキテクチャ/デザインの匂いは、トランザクションデータベースからの直接的な分析とレポートです。

これは確かにいくつかの状況（つまり、軽いレポート）では問題ありませんが、多くの場合、レポートとトランザクション処理の要件は矛盾しています。しかし、それは単純で安価なことなので、レポートはトランザクションDBから直接実行されます。これにより、方程式の両側にあらゆる種類の頭痛が生じます。

これは通常、エンタープライズLOBアプリで見られます。多くのSMBには、ウェアハウスとデータマートを作成するためのリソースやノウハウがない（キューブを忘れるか、またはマップを縮小する設定を忘れる）だけでなく、私が取り組んだ多くの大きな組織にも同じ問題があることを理解しています。

システムを設計するとき、アーキテクトは、レポート（特に分析レポート）とトランザクション要件が、データベースレベルでひとまとめにされるのではなく、個別の問題として最も適切に扱われることに注意する必要があります。

これがアーキテクチャレベルに適切に適合するかどうかはわかりませんが、オブジェクト指向設計であるはずのマネージャークラス/モジュールの束を見ると、それはアーキテクチャ/設計を理解する唯一の人が保証することです他の人による多くの説明/学習のない建築家/設計者自身です。

コミュニティによって文書化された多くのアーキテクチャの匂いがあります。一般的に発生するセットは次のとおりです。

• 周期的な依存関係：この匂いは、2つ以上のアーキテクチャコンポーネントが直接または間接的に相互に依存している場合に発生します。
• 不安定な依存性：この臭いは、コンポーネントがそれ自体より安定性の低い他のコンポーネントに依存している場合に発生します。
• 神のコンポーネント：この臭いは、LOCまたはクラスの数のいずれかでコンポーネントが過度に大きい場合に発生します。
• 機能の集中：この臭いは、コンポーネントが複数の建築上の懸念/機能を実現したときに発生します。
• 散らばった機能：この匂いは、複数のコンポーネントが同じ高レベルの懸念を実現する責任がある場合に発生します。
• 密な構造：この臭いは、特定の構造を持たないコンポーネントに過度の密な依存関係がある場合に発生します。

私は最近においの分類学を準備しました。現在、38のアーキテクチャの匂いと、260を超えるコードの匂いが記録されています。