2

システムをゼロから設計および開発してきた私たちの多くは、プロジェクトのアーキテクチャについて厳しい決定を下さなければならない状況にあります。アーキテクチャ的に健全でスケーラブルなシステムを構築するための「次のステップ」を実行する上で、どこに線を引きましたか。

アーキテクチャの面でかなり崩壊した大規模なWebサイトを構築しました。フロントエンドコードを含むWebレイヤーがあり、次に、実行する実際の作業を処理するビジネスレイヤーとデータレイヤーがありました。論理分離のさまざまなレイヤーが同じ物理マシン上に共存していました。Webサービスのレイヤー/層を使用することで、物理的または単純に論理的な分離が存在する可能性があります。さまざまな理由で、そのように実装されていませんでした。決定が正しかったか間違っていたかは、単に意見の問題です。私の観点からすると、比較的単純なアプリケーションが過剰に設計されている他の状況にあります。

新しいプロジェクトのアーキテクチャを設計する際に考慮する要素には、どのようなものがありますか？頻繁に使用する一貫したプロジェクト設計がありますか、最初からn層ですか、それとも各プロジェクトが入ってくるたびに評価しますか？

これらの経験を繰り返し経験していると、同じ立場にいる他の人がこれらの考慮事項をどのように正当化し、行うのか疑問に思うことがよくあります。私たち全員がさまざまな意見を持っていると思いますが、意見の背後にある思考プロセスを理解することは啓発的であると信じています。

4

7 に答える 7

3

特定の問題の正しいアーキテクチャは、問題に完全に依存します。あなたの質問は一般的すぎて本当の答えを提供できません。ただし、すべての既知および予想される要件を説明するためにアーキテクチャを可能な限り単純に保つと言う以外は、単純ではありません。

編集：

「典型的な」ビジネスソリューションの場合、私が考える要素のいくつかを次に示します。

  • UI

    • Webベースにすることはできますか？ユーザーインタラクションの要件は何ですか？
    • 従来のWebインターフェイスでは不十分な場合、Sliverlightなどのよりインタラクティブなテクノロジーを使用できますか？
    • シッククライアントである必要がある場合（はい、それを正当化するシナリオはまだあります）、展開の課題はどれほど深刻ですか？小さなユーザーベース、大きなユーザーベース？自動更新を含める必要がありますか？強制する必要がありますか？

  • ビジネスレイヤー

    • 物理的に別個のビジネスレイヤーを必要とするパフォーマンス/スケーラビリティの考慮事項はありますか？（私のビジネスレイヤーは常に論理的に分離されており、必要に応じて物理的に簡単に分離できます。Windowsを対象とする場合、展開時にCSLAを使用してその決定を可能にすることがありますが、これは重いフレームワークであり、常に適切であるとは限りません）。
    • 私のビジネスルールはどれくらい単純ですか、それとも複雑ですか？それらは時間とともにかなり進化する可能性がありますか？Droolsなどのルールエンジンを組み込む価値はありますか？
    • 非同期処理の要件はありますか？ワークキューシステムが必要ですか？
    • インターフェースする外部システムはありますか？それらにどのような種類のインターフェースがありますか？Webサービス、COM +、XML over HTTP、プロプライエタリ、DB、バッチファイル、...？

  • データの永続性

    • 既存のプラットフォームの選択肢/制約を考慮して、どのORMの選択肢を利用できますか？
    • ストアドプロシージャを多用することでメリットがありますか？ストアドプロシージャを維持し、時間の経過とともに変更するDBAはありますか？DBAがない場合は、パフォーマンスに本当に必要な場合にのみストアドプロシージャを使用します。DBAがある場合、ストアドプロシージャをより広範囲に使用すると、DBAは、アプリケーションから独立して物理アーキテクチャを管理できる柔軟性が得られます（ただし、複雑さが増すのと同様に、コストがかかります）。

  • クロスカッティング

    • セキュリティ要件は何ですか？統合する既存のメカニズム（Active Directory / LDAP / ...）はありますか？ロールベースのセキュリティをサポートする必要がありますか？
    • 運用監視の要件は何ですか？「このバグを報告する」機能？単純なロギング？
于 2009-08-12T02:07:18.883 に答える
2

ええと、私に言わせてください - ただそれをしてください。現在の要件に集中しますが、将来の可能性のあるすべての機能、架空の要件の変更、および開発のさまざまなコースに対処しようとしないでください。

Joel によって書かれた素晴らしい記事があります: Don't Let Architecture Astronauts Scare You .

あなたが持っている要件、ソフトウェアが必要とする機能が何であれ分析し、同様のプロジェクトでの以前の経験を見て、それを実行してください.

優れたアーキテクチャは、最初のブレイン ストーミング セッションからすぐには生まれません。1 つのアプローチから始めて、天候の変化に合わせて進路を調整し、アーキテクチャを改善するためのアイデアを生み出すコード レビュー セッションを行い、一部の悪いコード部分を再利用可能な優れたコンポーネントにリファクタリングし、最終的にガレージを城に変えます。

KISS の原則に従い、時期尚早の最適化を回避します。

よく使用する一貫したプロジェクト設計はありますか?

もちろん。個人またはチームは、独自のスタイル、典型的な問題を解決するためのテクニック、ツールセットを構成する再利用可能なコンポーネントを開発します。新しいプロジェクトを開始するたびにそれらを捨てるのはなぜですか?

最初からn層ですか？

私はそうしようとします。これは、一貫性、クリーンな構造、関心の分離という目標に役立ちます。

それとも、プロジェクトが入るたびに評価しますか

それも。問題に対処し、最も効率的な方法で解決する別の方法があるかもしれません。

于 2009-08-12T12:34:22.790 に答える
1

パフォーマンスのボトルネックを前もって想定することは、一般的に非常に悪い習慣だと思います。最終的に目立った違いをもたらさない事前の最適化に多くを費やすことができます.

最近では、優れたリファクタリング ツールがいくつかあり、開発パターンに関する多くのリソースがあります。ツールが非常に良くなったので、以前ほどアーキテクチャ機能に費やす時間が減りました。非常に大まかに私のプロセスは次のようなものです：

  1. 要件を収集する
  2. 要件に優先順位を付ける (金メッキ機能に多くの時間を費やさないでください)
  3. データとビジネス ロジック層が事前に分離されることがわかっていない限り、通常は 2 層 (UI / データとビジネス ロジック) から始めます。
  4. 要件ごとに、まずそれを機能させます。必要であることが痛々しいほど明白でない限り、ここにはパターンはありません。実装にはパターンの必要性が生じることがわかりました。
  5. 動作したら、コードをクリーンアップし、パターンの場所を特定し、必要な場合にのみ実装します
  6. パフォーマンスが必要な場合は、パフォーマンス テストを行い、必要に応じてリファクタリングします。

このように作業すると、単純さの側で誤りを犯していることに気付くでしょう。パターンやサードパーティのツールなどは、特定の問題を解決するのに非常に役立ちますが、そのようなものを追加するたびに、後でアプリケーションを維持するために必要な理解の水準が上がることを心に留めておきたいと思います. だから私は単純なものから始めて、それが特に何かを得るときにのみ複雑さを加えます。

小さくて単純なアプリケーションであっても、依存性注入フレームワーク、Nhibernate、NUnit に到達し、独自のログ ライブラリを作成し、3 倍のユニット テストを作成する他のアーキテクトを扱うとき、私は実際に口の中でかなり悪い味を覚えます。これらのツールにはすべて、ROI (投資収益率、「費用対効果」) が非常に優れている特定のインスタンスと、そうでない他のケースがあります。優れたアーキテクトは、最小限の時間とコストで最大限の価値を提供します。

于 2009-08-12T04:23:44.390 に答える
1

私の観察では、本当に優れたアーキテクトは、時間をかけて既知の要件を深く理解し、将来の柔軟性が提供される場所を理解するためにかなりの判断を下します。

また、階層の論理的分離と物理的分離の違いも理解しています。

以下の 2 つのパターンのいずれかをよく見かけます。

  • これは最後のプロジェクトで機能したので、ここで使用します...要件は異なりますが。
  • 以前は機能しなかったので、使用しません...機能しなかった理由は実装がうまくいかなかったからです

(対処する必要がある唯一のアーキテクチャの問題が、ソリューションにいくつの層を含めるかである場合は、本当に幸運です:-)

于 2009-08-12T12:19:11.703 に答える
1

構造的に健全でスケーラブルなシステムを構築するための「次のステップ」を踏む際に、どこで線を引きましたか?

質問のこの部分がわかりません。

新しいプロジェクトのアーキテクチャを設計する際に考慮した要因は何ですか? よく使用する一貫したプロジェクト設計がありますか?最初から n 層ですか?それともプロジェクトが入るたびに評価しますか?

私は幸運にもほとんどすべての仕事を小さなチームで行うことができましたが、運悪くほとんどすべての仕事を離職率の高いチームで行うことができました。私は、自分だけでシステムを設計しようとしないことを学びました。チームの努力により、結果はより良くなります。ラピッド プロトタイピングを行うこともありますが、チームが優れていれば、ホワイトボード、インデックス カード、および紙のデザインで驚くほど遠くまで到達できることがわかりました。

一貫したプロジェクト設計がありません。各アーキテクチャは、プロジェクトにとって 1 回限りのものである可能性がありますが、私は研究と高度な開発に専念してきました。

考慮される要因:

  1. チームは、アーキテクチャが仕事を成し遂げると考えていますか? 他のすべての考慮事項を切り捨てます。

  2. アーキテクチャは、経験の浅いチーム メンバーや新参者が簡単に習得できますか? 他のグループはあなたの最高の人材を盗み、会社を立ち上げるために去ります。あるケースでは、フィールド リクエストに対応するのに忙しすぎて新しいアーキテクチャを学ぶことができなかったグループがありました。

  3. アーキテクチャの構造は、それを作成する必要がある組織の構造を反映していますか? :-) 多少の冗談は言うまでもありませんが、完璧な開発チームではなく、私たちにある人々と時間でそれを構築できると信じる必要があります。したがって、個人に一致するアーキテクチャの部分を特定できることは良いことです。

  4. 理解できない部分はありますか? さらに悪いことに、恐れている部分はありますか? もしそうなら、重大な危険信号です。

  5. それは美しいですか？他のチームの人々と昼食時に話すことを誇りに思うことはありますか? そうでない場合は、設計/アーキテクチャがまだ十分ではない可能性があります。

  6. 識別可能な新しいアイデアはありますか？他の人が学べる何か？(これは研究環境では重要ですが、他の場所では重要ではないと思います。)

于 2009-08-12T03:23:26.430 に答える
0

私はSpringを使用しています-それはすべて組み込みです。

于 2009-08-12T02:06:09.163 に答える
0

I initially consider the complexity of the domain. If complex and in business, commerce or industry, rather than computer or data sciences, I default to an architecture based on an object domain model.

I next consider size, criticality, expectations and other non-functional requirements.

于 2016-04-14T13:32:11.737 に答える