建築のにおいはありますか？
コードのにおいを参照してリストするWebには、たくさんのリソースがあります。ただし、建築のにおいに関する情報を見たことがありません。これはどこかで定義されていますか、そして利用可能なリストはありますか？アーキテクチャの欠陥、およびプロジェクトの速度、欠陥などへの影響について、正式な調査は行われましたか？
編集：答えのリストを実際に探していたのではなく、アーキテクチャのにおいに関するドキュメント（Webまたは本）を探していました。
- 多層アーキテクチャLayers on Layers on Layers on Layers ... Layers on Layers on Layers ... Layers on Layers on Layers on Layers ...私はそれをOver Layered Architectureと呼びます
- 抽象化よりもコードで迷子になるような方法で。
- 未来的なアーキテクチャこれは、ソリューションが未来的すぎる場合に発生します。実際には、新しい要件を予測することはできません。したがって、ほとんどの未来的な実装は、時間とリソースを浪費するだけです。
- テクノロジーの熱狂的なアーキテクチャ建築家は新しいテクノロジーが好きで、生産を開始しました。それが以前に証明されたかどうかを知ることなく。
- Over Kill Architecture単純な問題が、アーキテクチャのスキルとテクノロジーの指数関数によって解決されました。
- クラウドアーキテクチャアーキテクチャは実際には接続されていないため、私はそれをクラウドアーキテクチャと呼びます。これは、いくつかの素晴らしいVisio図です。
反対の完全な欠如も真実です。
こちらが ソフトウェアアーキテクチャの誤りトップ1 のリンクです。
すべて設定可能。広範囲にわたる構成が可能なため、設計者が自分のシステムは変更に対応できない、または高度にカスタマイズ可能であると言ったとき、それはアーキテクチャの匂いです。
問題は、実際に構成する必要があると考えているものに対してのみ構成メカニズムを提供できることですが、アプリケーションが一般に公開されると、それだけでは不十分です。次に、構成メカニズムが展開して展開し、最終的には内部プラットフォーム効果が得られます。
そして、あなたはソフトウェアの地獄にいます。
ORMが設計したデータベース！または、リレーショナルである必要がある非リレーショナルのデータベースバックエンド。または、ビューを呼び出すビューを使用するビューを使用するように設計したデータベースは、ビューが遅いだけでなく（最初からパフォーマンスを向上させるようにデータベースを設計する必要があります）、変更を加える必要がある場合、追跡するのが非常に困難です。 （@AmirResaeiが言ったように抽象化よりも、それらすべてのレイヤーの最下部にある何かを修正する必要がある場合、コードで迷子になりやすくなります。）
コードの匂いと建築の匂いは同じものです。アーキテクチャが最適ではないため、コードは「におい」を始めます。
マーティンファウラーのこのトピックに関する独創的な本（Refactoring）で、彼は一連のコード臭を提示し、システムからそれらをリファクタリングする方法を特定します。 Joshua KerievskyのRefactoring to Patternsは、特定のアーキテクチャパターンを提供してさまざまなコードの臭いを修正することで（および段階的にリファクタリングする方法）、このアイデアをさらに強調しています。
ほとんどのリファクタリングは、拡張アーキテクチャを介して次善のコードを軽減するために行われます。自然に生まれた唯一の「建築の匂い」（Big Ball of Mud以外）は、BDUF（Big Design Up Front）建築であると主張することができます。コードの最初の行が記述される前に、必要なすべてのものに対応しようとする場合。必要に応じて設計が行われるアジャイルソフトウェアプロジェクト（私は コードは 扱われる 設計として をあえて言う）でも、そのアーキテクチャを有機的に拡張します。
これは、私が常に遭遇する具体的なアーキテクチャ/設計の匂いです。トランザクションデータベースから直接分析およびレポートします。
これは確かに一部の状況（つまり、軽いレポート）では問題ありませんが、多くの場合、レポートとトランザクション処理の要件は矛盾しています。ただし、これは簡単で安価なことなので、レポートはトランザクションDBから直接実行されます。これは、方程式の両側にあらゆる種類の頭痛の種を引き起こします。
これは通常、エンタープライズLOBアプリでよく見られます。多くのSMBには、ウェアハウスやデータマートを作成するためのリソースやノウハウがない（キューブを忘れるか、マップ削減のセットアップを行う）だけではないことを理解していますが、私が扱ってきた多くのより大きな組織にも同じ問題があります。
システムを設計するとき、アーキテクトは、レポート（特に分析レポート）とトランザクション要件をデータベースレベルでひとまとめにするのではなく、個別の問題として扱うのが最善であることを認識しておく必要があります。
（たくさんの） Coupling --どんな形でも-アーキテクチャの匂いを嗅ぐものです。結合すればするほど、においがします。
とはいえ、カップリングがまったくない場合は、パフォーマンスの問題の臭いがします。
これがアーキテクチャレベルで適切に適合するかどうかはわかりませんが、OOの設計であると想定されているものに一連のマネージャークラス/モジュールが表示された場合、それは建築/デザインを理解する唯一の人は、他の人による多くの説明/学習なしで建築家/デザイナー自身です。
コミュニティによって文書化された多くの建築臭があります。一般的に発生するセットは次のとおりです。
- Cyclic Dependency：このにおいは、2つ以上のアーキテクチャコンポーネントが直接的または間接的に互いに依存している場合に発生します。
- 不安定な依存関係：このにおいは、コンポーネントが、それ自体よりも安定性が低い他のコンポーネントに依存している場合に発生します。
- 神のコンポーネント：このにおいは、LOCまたはクラスの数のいずれかでコンポーネントが過度に大きい場合に発生します。
- 機能の集中：この臭いは、コンポーネントが複数のアーキテクチャ上の懸念事項/機能を実現したときに発生します。
- 散らばった機能：このにおいは、複数のコンポーネントが同じ高レベルの懸念を実現する責任があるときに発生します。
- 密な構造：このにおいは、コンポーネントに特定の構造がなく、依存関係が過度に密である場合に発生します。
私は最近 匂いの分類 を用意しました。現在、38のアーキテクチャのにおいと、260を超えるコードのにおいが記載されています。