リードが示唆するように、このプロジェクトの設計を中止して、このプロジェクトの設計を開始するにはどうすればよいですか？[閉まっている]

私はジュニア開発者（経験3年以下）であり、仕事では新しいシステムを設計しています。私の主任開発者はプリンシパルアーキテクトになりますが、彼はシステムを自分で（並行して）設計しようと挑戦しました。

アイデアをブレインストーミングし、私がアーキテクチャの提案として見たものを提案するいくつかのイテレーションの過程で、私のリードは私がやっていることのほとんどが「設計」ではなく「設計」であるというフィードバックを私に与えました。

彼は、設​​計は実装の記述であるのに対し、アーキテクチャは実装に依存しないと説明しました。彼は、デザイナーの帽子を脱ぎ、建築家の帽子をかぶる必要があると言いました。彼は私にそうする方法について少しアドバイスをくれましたが、私もあなたに尋ねたいと思います：

ソフトウェアデザイナーモードから抜け出し、アーキテクトのように考え始めるにはどうすればよいですか？

ここに、私が思いついた「デザイン」の例をいくつか示しますが、それは私のリードではアーキテクチャに関連するとは見なされませんでした。

1. 私たちのシステムからリソースをロードおよびアンロードするためのアルゴリズムを思いつきました。私のリードは、アルゴリズムは明確にアーキテクチャではないと述べました。
2. システムが発生させる一連のイベントと、それらを発生させる順序を考え出しましたが、これもアーキテクチャとしてそれを削減するようには見えませんでした。

私は細部に巻き込まれ、十分に後退していないようです。アーキテクチャレベルの何かを思いついたとしても、さまざまな実装を試し、詳細をいじってから一般化して抽象化することで、そこにたどり着くことがよくありました。これをリードに説明したとき、彼は間違ったアプローチを取っていると言いました。「ボトムアップ」ではなく「トップダウン」を考える必要がありました。

以下に、プロジェクトに関する具体的な詳細を示します。

• 設計しているプロジェクトはWebアプリケーションです。
• およそ10〜10万行のコードを見積もっています。
• 私たちは新興企業です。当社のエンジニアリングチームは約3〜5人です。
• 私たちのアプリケーションと比較できる最も近いものは、軽量のCMSです。同様の複雑さを持ち、主にコンポーネントのロードとアンロード、レイアウト管理、プラグインスタイルのモジュールを扱います。
• アプリケーションはajax-yです。ユーザーはクライアントを一度ダウンロードしてから、サーバーに必要なデータを要求します。
• MVCパターンを使用します。
• アプリケーションには認証があります。
• 古いブラウザのサポートについてはあまり心配していません（なんと！）ので、私たちは世の中にあり、今後出てくる最新かつ最高のものを活用したいと考えています。（HTML5、CSS3、WebGL？、Media Source Extensionsなど）

ここではいくつかあるプロジェクトの目標は：

• アプリケーションはスケーリングする必要があります。近い将来、私たちのユーザーは数百から数千のオーダーになりますが、数万から数百万以上を計画しています。
• アプリケーションがいつまでも続くことを願っています。これは一時的な解決策ではありません。（実際には、私たちはすでに一時的な解決策を持っています。私たちが設計しているのは、私たちが持っているものの長期的な置き換えです）。
• 機密性の高い個人情報との接触がある可能性があるため、アプリケーションは安全でなければなりません。
• アプリケーションは安定している必要があります。（理想的には、Gmailのレベルで安定しますが、火星探査機の極端にある必要はありません。）

まず第一に、アーキテクチャとデザインの違いは主にセマンティクスだと思います。一部のチームには、2つの間にチェックポイントがあります。テクニカルリードは、アーキテクチャを以前のように定義し、アーキテクチャを実装非依存として定義します。そのことから、ソフトウェアアーキテクチャに到達する前にユーザーに向けて製品を設計するのに役立つ工業デザインではなく、ウォーターフォールモデルのようなデザインについて話していると思います。建築はしばしば設計に滑り込むと思いますが、それは必ずしも悪いことではなく、建築家が手元のシステム内で可能なことについて深い知識を持つことはしばしば非常に役立ちます。

そうは言っても、現在の状況に対するアドバイスが必要です。ソフトウェアアーキテクチャの世界には論文、書籍、会議がありますが、通常はパターンと抽象化を探しています。プロジェクトの詳細がなければ、私は大まかな例を挙げることができます。たとえば、統合で作業している場合は、サービス指向アーキテクチャ（SOA）システムの各部分を「サービス」に分割して、各部分を定義された方法で操作できるパターン。Webプログラムでは、これをWebサービスとして実装することがよくあります（ただし、それに限定されるべきではありません）さらに最近では、JSONを使用したRESTful APIの登場もありますが、これもSOAのアーキテクチャに由来する設計だと思います。Model、View、Controller（MVC）は、一般的に使用されているアーキテクチャパターンの別の例であり、システムのコンポーネントの責任を分割して、部品の交換、エラーの抑制、テストを可能にします。

10,000フィートのレベルから、それをホワイトボードに描いて、自分の分野で働いておらず、プログラミング言語と現在の実装の詳細を知らない有能なプログラマーに説明できるなら、おそらくアーキテクチャでしょう。あなたの会社の外部の誰もが気にするような本を書くことができるなら、それはおそらく建築でしょう。自己説明的な詳細を見つけて、他のコードベース/企業/産業に一般化できない場合は、おそらく設計です。

皆さんがお伝えする2つの例は、アーキテクチャではなくコード設計であることに同意します。最初の理由は、リソースをロードするための「アルゴリズム」を思いついたと言うとき、そのタスクを達成するための一連の指示を設計したのではなく、彼らが1年目に教える新しいアルゴリズムを設計したのではないと思うからですCOMSC来年。2番目の例では、やはりデザインであることに同意します。これらのアイデアのいずれかを見せてくれたら、ランダムなソフトウェアプロジェクトでそれらを使用することはできません。CustomerクラスをPersonクラスのサブクラスにしたいのではなく、Javaの「高レベル」のオブジェクト指向（OO）に移動する必要があります。一般的に例外について話すことは、低すぎるレベル（実装に近すぎる）と見なすこともできます。

あなたがリストした詳細に対処するために、あなたが考えるべきことはウェブベースのCMSをどのように設計するかだと思います。Wordpressにはサイトアーキテクチャのコーデックスがあり、設計実装の詳細について多くのことを話しますが、メインアーキテクチャがWordpressをテーマで拡張可能にすることに重点を置いていることは投稿から明らかです。社外の誰かが書くことができるようにテーマの明確なインターフェイスを設計することは、明らかに彼らが行ったアーキテクチャの決定でした。これらは、（長期的）（一時的ではない）ソリューションを設計する際に紙に書き留めておくとよいものです。開発中に（設計者だけでなくすべての開発者によって）行われるすべての設計と実装の決定この考えに沿っています。

状況に応じたアーキテクチャの他の例：

1. クラウドプロバイダーまたは社内でホストされ、ステートレスマシンインスタンスを備えた仮想マシンにすべてを置くことで、状態がコピーされたり情報が失われたりすることなく、障害が発生したマシンを仮想マシンの新しいインスタンスに置き換えることができます。
2. 混の仲間との最初からの実稼働での障害テストを 組み込みます。

システム全体をホワイトボードに描いてみてください。さまざまな詳細レベルで試してみてください。最初のボードはGUI-> dispatcher-> backend-> DBなどで、代名詞の使用を開始するまでドリルダウンします。

これらの2つのアイデアの違いは、私が仕事をしている場所では本当に重要です。

「アーキテクチャ」と呼ばれるものを、「英語でのプログラミング」と呼びます。プログラマ以外の人に説明できない場合、何かが間違っているため、これは部分的に重要です。問題を十分に理解していないか、「ファントム」問題（ここでは説明していません）を解決している可能性があります。

設計のこれら2つの異なる側面に使用される用語は異なる場合がよくありますが、原則はどこでも容易に認識されます。1つの側面（あなたの場合は建築家、私の場合はデザイナー）は英語でプログラムし、もう1つの側面（あなたの場合は「デザイナー」、私の場合は「開発者」）は特定の言語でプログラムします。また、それらは「デザイン」と「実装」として非常に一般的に区別されます。「設計」は達成すべきことであり、「実装」はそれを実現するコードです。

私が取り組んだことのいくつかの例：

1つのプログラムのアーキテクチャは次のとおりです。モジュールを簡単に追加できる集中マネージャーまたはハブが必要です。このManagerは、登録されたすべてのモジュールにイベントを配布します。モジュールは自身をイベントマネージャーに登録することができ、それによりイベントをシステムの残りの部分に発行し、気になるイベントを受け取ることができます。各モジュールには「メールボックス」があり、必要に応じてチェックしたり空にしたりできます。これにより、まだ必要なことがわからない新しいモジュールに対応できます。

コードはありません。任意の言語で記述できます。実装は、この説明によって決定されるものではありません。

別のプロジェクトのアーキテクチャは次のとおりです。他のプログラムを待たずに確実に起動および停止する方法が必要です。特定のプログラムを担当するマネージャーを置くこともできます。プログラムを開始または停止するように指示するだけで、マネージャーが処理します。この他のプログラムが停止するように要求され、所定の時間内に停止しない場合、マネージャーは強制的に停止する方法を知っており、混乱をクリーンアップします。プログラムは他の何かによって開始または停止されることはなく、マネージャーはそのプログラムが実行中、停止中、または停止待機中かどうかを尋ねられます。これにより、他のプログラムを適切に開始および停止しながら、必要な他の作業を続行できます。

繰り返しますが、ここでは実装を指示するものはありませんが、いくつかの実装は明らかに他のものよりも有用です。

設計（パターンまたは実装と呼ぶ）とアーキテクチャ（設計と呼ぶ）の違いは、一方がコーディング/実装の問題を解決し、もう一方が現実の問題を解決することです。

たぶんこれが役立つでしょう。私はいつも、エンジニアの年功序列を、彼らが自分で解決できる問題の大きさの問題だと考えてきました。

大まかに、アイデアを伝えるために：

• タスクを他の部分と統合する方法についての多くの明示的な指示とともに、小規模で包含されたタスクのプログラミングに新しい人を与えることができます。

• 中間レベルの開発者は、アプリケーションの一部の説明を取得し、そのアプリケーションのコンテキスト内で機能させることができる人です。

• 上級開発者は、ショップの技術的な制約内で、中規模のアプリケーションをゼロから構築できます。

• より上級の開発者はそれを行うことができ、それをうまく機能させるためにどのテクノロジーを使用するかについて、途中でテクノロジーを選択できます。

...しかし、それらは難しくて速い規則ではありません。また、別のタイトルで時間を費やす必要がある場合でも、一部の人々は「シニア」IMHOとしてゲートから出てきます。

建築家が求めているのは、問題をそれよりももっと一般的に見ることです。システムを動作させるためにいくつかのアプリケーションをまとめる必要がある場合：

• どのアプリケーションとサービスが必要ですか？
• どの部分が顧客と相互作用し、どの部分が相互作用しますか？
• 彼らはどのように通信しますか？
• データはどこに保存されますか？
• 失敗のリスクはどこにありますか？
• 信頼性はどのように提供しますか？
• セキュリティをどのように提供しますか？

したがって、ある意味で、技術的アーキテクチャは建物のアーキテクチャに似ています。それはレイアウト、または計画です。さまざまなパーツに必要なもの、それらがどのように結合するか、そして同様に重要な理由を示しています。

（ところで、関連するアプリケーションのファミリや非常に複雑な機能のセットの設計から、グループの技術的な方向性の設定、組織全体の戦略的な技術的決定に至るまで、同様の成長曲線を設計者に説明してきました。 ）

そうは言っても、すべてのレベルのほとんどのエンジニアは「アーキテクト化」も行わなければならないと思います。それは明るい線ではありません。最初に全体像に焦点を合わせ、実装の詳細にこだわらないようにすれば、彼が探しているものともっと一致するように思えます。ちなみに、この業界では、全体像と細部を見ることができることは大きな資産であるため、これは大きなチャンスのように思えます。

...これは類推です。マジックブラックボックスを作成するように求められたとします。エンジニアとして、あなたはマジックブラックボックスの内部の仕組みに夢中になることが期待されています。しかし、建築家としてのあなたの焦点は異なります。あなたは好奇心から箱の中を覗くかもしれませんが、あなたはすべてのマジックブラックボックスの周りのすべてに夢中になることが期待されています。

その類推と同様に、システム全体を魔法の箱として見ているアーキテクチャーの役割について考えるかもしれません。巨大なガラスボックスを用意して、顧客、クライアントアプリ、ファイアウォール、サービス層、データベース、さらにはdevopsの人たちを入れたら、アーキテクトとして、その巨大なシステムボックスの作り方に夢中になります仕事も。

「デザイン」と「アーキテクチャ」の正確な違いは少し主観的であり、いくつかの重複があります。しかし、これは私が理解しているように違いです：

アーキテクチャは高レベルの概念に注目します。システム内のアクターは誰ですか？主要なオブジェクトは何で、どのオブジェクトが何に責任を負いますか？アーキテクチャを考えるとき、コードではなくVisioを考える。

たとえば、イベントシステムには、着信イベントを受け入れてイベントハンドラーにディスパッチするイベントマネージャーがあります。ここでは、スレッド、非同期対同期、およびその他の低レベルの概念の概念は役に立たない。MVCは別の例です。特定の詳細は、3つの部分がどのように相互作用するかの高レベルでは指定されず、別々のコードパッケージで処理される3つの個別の懸念があります。

設計には、プロトタイピング、コードインターフェイスのスケッチ、コードスケルトンなどが含まれます。これは、抽象アーキテクチャと低レベルの「コードモンキー」作業の間に位置します。

イベントフレームワークでは、デザインは「イベントはこのインターフェイスを使用します」、「イベントマネージャーがイベントをワーカーにディスパッチするために使用するスレッドプールがあります」と言う場合があります。MVCの設計は、「モデルにHibernateを、コントローラーにSpringを、ビューにGWTを使用する」かもしれません。

設計作業を行うとき、インターフェイスとコードスケルトンをスケッチし、その結果をプログラマに渡します。時々私はそのプログラマーです。しかし、それは2つの別々のフェーズであり、両方ともアーキテクチャよりも具体的なものに向かって存在します。

アーキテクチャの帽子をかぶるということは、コードを意識し、ホワイトボード上のオブジェクトを考えることを意味します。オブジェクト、パッケージ、フレームワーク、およびそれらの間のメッセージの流れを考えてください。1行のコードさえ考えているのなら、それは間違っています。「ああ、そのメッセージは文字列かもしれないし、SOAPを使っているかもしれない」などのように動揺しないでください。このレベルでは、通信が行われているという事実で十分です。詳細は関係ありません。

ここに何かを追加できる場合、それは次のとおりです。コードを考えないでください。まったく。

何かを達成するためにコードをどのように書くかを考えないでください。しかし、それを達成するための最良の 方法は何であるかを考えてください。何をする必要があるかについての説明は言語にとらわれないようにする必要があります。そのため、異なるプログラミング言語のユーザー間で共通の「言語」であるデザインパターンについて話し、前進する方法について話し合います。

あなたの特定のユースケースについては、私の意見ではより多くのアーキテクチャ上の質問は次のようなものになります：

• なぜMVCを使用しているのですか？あなたが知っているすべてですか？使用するより良いパターンはありますか？どうして？
• どのフレームワークを使用しますか？その理由は何ですか？
• どのようにスケーリングしますか？それはまだ問題ではないので、コードに関してはそうではありません。水平にスケーリングするための条件は何ですか。これを行うためにどのサービス（AWS）を使用しますか？
• 認証はどのように実行されますか？コードごとではありません：各リクエストでランダムな一意のトークンを生成し、予想されるトークンと照合しますか？コードでこれを行う方法を考えないでください。なぜこれをしているのかを考えてみてください-これは事実上すべてのWeb言語で実行できるからです。

基本的に、コードについては一切話さないでください。あなたが何かをする方法を知らなくても、意志があるとき、方法があります。実際にパズルを組み立てるのを心配する前に、パズルのピースがどのように最適に組み合わされるかについて考えてください。

システムが実行できるすべての操作（ユースケースなど）を考えてください。各操作について、各操作のビジネスドメインに関して何が起こるかを文書化します。問題領域の観点からのみ話し、実装の詳細については説明しないでください。大きなブロックを描き、それをシステムと呼びます。この「大きなブロック」と操作の説明の組み合わせは、最高レベルのシステムアーキテクチャです。

この高レベルのアーキテクチャはまともな出発点を提供しますが、実際のシステムを構築する際にはあまり価値がありません。これを有用なアーキテクチャに変えるには、詳細を1レベル下げる必要があります。

したがって、各操作を実行するために必要な「サブブロック」を追加し始めるだけで、「ビッグブロック」アプローチと同じ一般的な考え方に従います。これらの「サブブロック」は、ドメインクラスまたはモジュールと呼ばれることがよくあります。これらは、操作の説明（ビッグブロックアプローチから）とシーケンス図を使用して簡単に識別できます。それらは「実際の」クラスを意図していないため、ドメインクラスと呼ばれますが、システムの問題ドメインの観点からシステムを記述することを目的としています。

すべてのシーケンス図を作成し、すべての「サブブロック」を識別することの最終結果は、ドメインクラスのリストとそれらの操作のリストがあることです。通常、これはかなり使いやすいソフトウェアアーキテクチャになり、「サブブロック」/モジュールのそれぞれを設計および実装するために異なる開発者に分割することができます。

もちろん、そのままにしておくと、設計者はモジュール間のインターフェースを定義する際に互いに多くのやり取りをすることになります。したがって、アーキテクトは、モジュール間で使用する特定のインターフェイスメカニズムとデータ型を決定することもできます。

また、一部の「サブブロック」は依然として非常に複雑です。したがって、「サブブロック」アプローチの別の反復が必要になる場合がありますが、今回は新しく識別されたモジュールの1つに対してのみです。

最後に、アーキテクトがシステムに準拠させたいインターフェース間に特定のパターン/制限がある場合があります（たとえば、イベントコールバックと直接メソッド呼び出し）。これらの決定は、アーキテクチャ設計で話し合う必要があります。さらに、アーキテクトが全員に使用してほしい「共通」モジュールが存在する場合があります。

開発者として、おそらくソリューションを提供することに慣れているでしょう。それは非常に良い考え方ですが、建築について考えると邪魔になるかもしれません。

最初に解決しようとしている問題を説明するのに役立つことがわかりました。要件は何ですか？制約は何ですか？これらの要件を見つけるために利害関係者と話をすることはできますか？

独自の設計目標についても説明できると役立つ場合があります。ソリューションを拡張する必要がありますか、それとも単一ユーザー向けの設計で十分ですか？ソリューションの有効期間はどのくらいですか？1回限りの修正ですか、それとも長期的なインフラストラクチャソリューションですか？おそらく同様に重要です：アーキテクチャの許容限界は何ですか？

そして、これは学習経験であるため、たとえ愚かであっても、質問することを恐れないでください。