ここ数年、変化していない仮説を再検討する時が来ました。 動的に変化する世界は、コンピューターアーキテクチャを含む独自のルールを規定します。 行われている変更には新しいアプローチが必要であり、厳格なシステムを柔軟にし、新しい条件に適応させる必要があります。 すべてが絶えず変化している場合、長期計画は可能ですか？ 時間の経過とともにアーキテクチャソリューションが徐々に劣化するのを防ぐ方法 ここでは、継続的な変更のコンテキストでプロジェクトの最も重要な特性を保護する回答と推奨事項を見つけます。 「この本は、問題の現在の理解における重要なマイルストーンを示します。 21世紀の人々がソフトウェアの役割に気付くにつれて、達成されたものを維持しながら変化に対応する方法に関する情報は、ソフトウェア開発に不可欠なスキルになります。」-Martin Fowler
進化的アーキテクチャ：トラップとアンチパターン
アーキテクチャにおける接続の適切なレベルについて議論するのに多くの時間を費やしました。 しかし、私たちは現実の世界にも住んでおり、プロジェクトの進化能力を損なう多くの相互接続を観察しています。
ソフトウェアプロジェクトで明らかな2つの悪い設計手法が特定されています。トラップとアンチパターンです。 多くの開発者は、アンチパターンという言葉をスラングの用語「悪い」として使用していますが、その本当の意味を明確にする必要があります。 アンチパターンソフトウェアは2つの部分で構成されています。 最初の部分：アンチパターンは、最初は良いアイデアのように思えますが、間違いに変わるプラクティスです。 第二部：ほとんどのアンチパターンには、はるかに優れた選択肢がたくさんあります。 アーキテクチャ開発者は多くのアンチパターンに気付くだけで、それを避けることは困難です。 一見、このトラップは良いアイデアのように見えますが、すぐに悪い方法として現れます。 この章では、トラップとアンチパターンを一緒に見ていきます。
技術的アーキテクチャ
このセクションでは、業界で使用される一般的なプラクティスに焦点を当てています。これは、アーキテクチャを進化させるチームの能力に特に有害です。
アンチパターン：ベンダーキング
一部の大企業は、会計、在庫管理、その他の日常業務などの一般的なビジネス上の問題を解決するために、エンタープライズリソースプランニング（ERP）ソフトウェアを購入しています。 これは、企業がこのツールを適応させるためにビジネスプロセスや他のソリューションを曲げる準備ができている場合に機能し、アーキテクチャ開発者が制限と利点を理解したときに戦略的に使用できます。
ただし、多くの組織はこのカテゴリのソフトウェアに関して過度に野心的になり、ベンダーキングのアンチパターンにつながります。ベンダーキングのアーキテクチャは、サプライヤーの製品に完全に基づいており、病理学的に組織をこのツールに結び付けます。 サプライヤーのソフトウェアを購入する企業は、プラグインを使用してパッケージを増やし、基本機能を拡張して企業の対象分野に合わせてパッケージを増やすことを計画しています。 ただし、長い間、ERPツールは必要なものを完全に実現するために十分に構成することができず、開発者はツールの制限の結果として、またそれがアーキテクチャユニバースの中心になったために無力です。 つまり、アーキテクチャの開発者は、アーキテクチャの王様のサプライヤーを作り、将来の決定を決定しました。
アンチパターンを回避するために、最初は幅広い責任を負っていたとしても、ソフトウェアを単に別の統合ポイントと見なす必要があります。 初期段階での統合を想定すると、他の統合ポイントで役に立たない特性を変更しやすくなり、王座から王を倒すことができます。
外部ツールまたはプラットフォームをアーキテクチャの中心に配置することにより、開発者は2つの主要な方向、つまり技術的およびビジネスプロセスの観点から進化する能力を大幅に制限しています。 開発者は、ストレージシステム、サポートされているインフラストラクチャ、およびその他の多くの制限に関して、サプライヤーの選択により技術的に制限されています。 サブジェクト領域の観点からすると、大きなカプセル化ツールは最終的に「最後の10％のトラップ」アンチパターンの影響を受けます。 ビジネスプロセスの観点から、このツールは最適なワークフローをサポートできません。 これは、最後の10％の副作用またはトラップです。 ほとんどの企業は、ツールをカスタマイズしようとするのではなく、プラットフォームにサブミットし、プロセスを置き換えてシャットダウンしました。 多くの企業がこれを行うほど、企業間の特徴は少なくなります。違いは利点ではないため、これは素晴らしいことです。
原則として、作業を止めて成功と呼びましょう。これは、開発者が現実の世界でERPパッケージを扱う際に通常考慮するものの1つです。 彼らは多大な時間とお金の投資を必要とするため、企業は彼らが働いていないときに同意することに消極的です。 数百万ドルの損失を受け入れることを望んでいる技術部門はありません。また、ツールのサプライヤは、貧弱な多層実装を受け入れたくありません。 したがって、各当事者は、作業を停止し、未実現のほとんどの約束された機能で成功と呼ぶことに同意します。
アーキテクチャをサプライヤキングに関連付けないでください。
サプライヤーキングのアンチパターンの餌食になる代わりに、サプライヤー製品を別の統合ポイントとして検討することを検討してください。 開発は、統合ポイント間の破壊に対する抵抗の層を構築することにより、サプライヤのツールの変更をアーキテクチャの影響から分離できます。
トラップ：穴あき抽象化
すべての非自明な抽象化は、ある程度まで穴でいっぱいです。
-ジョエル・スポルスキー
最新のソフトウェアは、オペレーティングシステム、プラットフォーム、依存関係などの抽象化の塔にあります。開発者として、私たちは下位レベルにいる間は常に考えることができないように抽象化を構築します。 開発者がハードドライブからの2進数をプログラムのテキストに変換する必要がある場合、彼らは何もできません！ 最新のソフトウェアの勝利の1つは、効果的な抽象化をどれだけうまく構築できるかです。
しかし、完全な抽象化は存在しないため、抽象化は高価であり、抽象化は抽象化ではなく、現実のものになります。 Joel Spolskyによると、すべての重要な抽象化には穴（リーク）があります。 抽象化は常に正確であると信じているため、これは開発者にとっては問題ですが、しばしばそれらは見事に崩壊します。
テクノロジースタックの複雑さの増大により、抽象化は壊滅的な問題になりました。 図 7.1は、2005年頃の典型的な技術スタックを示しています。
このスタックでは、ブロックのベンダー名はローカル条件に応じて変わります。 時間が経つにつれて、ソフトウェアがより専門的になるにつれて、図1に示すように、テクノロジースタックはより複雑になります。 7.2。
図に見られるように 7.2、ソフトウェアエコシステムの各部分は拡大し、より複雑になりました。 開発者が直面する問題がますます複雑になるにつれて、そのソリューションも複雑になります。
低レベルの破壊的抽象化が予期しないカオスをもたらす最初の穴のある抽象化は、テクノロジースタックの複雑さを増す副作用の1つです。 最低レベルの抽象化の1つが失敗した場合、たとえば、一見無害なデータベース呼び出しによる予期しない副作用が発生した場合はどうなりますか？ レイヤーが非常に多いため、この失敗はこのスタックの最上部に移動し、パスに「転移」を引き起こし、UIに深く埋め込まれたエラーメッセージとして現れます。 技術スタックが複雑になるほど、デバッグと遡及分析は難しくなります。
普段作業しているレベルより下の少なくとも1つの抽象化レベルを完全に理解するようにしてください。
-賢人ソフトウェア
下の層を理解することは良いアドバイスですが、ソフトウェアが専門化し、より複雑になるにつれて従うことがますます難しくなっています。
技術スタックの複雑さを増すことは、動的平衡問題の一例です。 エコシステムが変化するだけでなく、その構成要素は時間とともに複雑になり、混乱します。 進化する変化を保護するために提案されたメカニズム、すなわちフィットネス関数の使用は、アーキテクチャ接続の脆弱点を保護できます。 アーキテクトは、展開パイプラインの一部として機能するフィットネス関数などの主要な統合ポイントで不変式を定義し、抽象化が望ましくない方法で流れ始めないようにします。
»本の詳細については、出版社のウェブサイトをご覧ください
クーポンのhabrozhitelami 20％割引- 進化的アーキテクチャ