アーキテクチャ-宣言的。実装-必須。他のすべてはBureaucracyです

アーキテクチャとは何ですか？アーキテクチャはデザインとどう違うのですか？アーキテクチャと実装の境界はどこにありますか？建築が見えますか？アーキテクチャをテストできますか？アーキテクチャに対するエンジニアリングアプローチと進化的アプローチの違いは何ですか？良いアーキテクチャとは何ですか？アーキテクトの仕事は何ですか？開発者の仕事とどう違うのですか？アーキテクトはどのようなツールを利用できますか？実装とは別にアーキテクチャを変更することは可能ですか？アーキテクチャにはDNAがありますか？







tomaszjaniakブログからの画像

あなたのアーキテクチャを見せてください

たまたまプロジェクトに数年取り組んでいて、今はコードのひじに腰を下ろしていて、テストが燃えていて、ラップトップクーラーが音を立てて、コンパイラーによって過熱されたプロセッサーの熱を冷却しようとしています。あと数時間で、リファクタリングは終了します。そして、私たちは緊急にすべてを削除し、プロジェクトのアーキテクチャを描く必要があります。大規模なクライアントが計画されており、取引を成立させるためには監査を受ける必要があります。そしてこの場合、建築図なしではどこにもありません。それで、プロジェクトがまだ小さく、実際の作業で数十人の開発者がそこにアーキテクチャを必要としなかった場合はどうなるでしょうか。これがコードです-すべてが明確です。しかし、逃げ道はありません。それは必要です-そしてそれは必要です。



すべてがどのように機能するかを知っていれば、どの製品のアーキテクチャも1時間で描くことができます。そして、これは通常、監査には十分です。結局のところ、監査のポイントは、部外者が製品アーキテクチャを実際に理解することではありません。問題の要点は、製品開発者自身が自分たちのしていることを理解しているかどうかを判断することです。そして、自信を持って話し、ためらうことなく質問に答えれば、すべてがスムーズに進みます。しかし、それでも、この話が終わると、ワームがどこかに落ち着き、問題が明確になります。それでも、製品には実際にどのようなアーキテクチャがありますか？結局のところ、彼らが尋ねれば、おそらく他の人はアーキテクチャを持っています。そして、私たちがそれを持っていない場合、これは明らかに混乱です。次回のアーキテクチャに責任を持つために、すべてをうまくやりたいという大きな願望があります。



どうやってそれを正しくしますか？図を描き、ドキュメントの機能を説明してから、これらすべてを最新の状態に保つ必要があります。次に、アーキテクチャになります。しかし、作業の範囲を提示した後、これはすべて時間を費やす価値がないことがすぐに理解されます。これがコードです-すべてが明確です。そして、別のクライアントが来た場合、さらに1時間以内に、新しい図を描くことが可能になります。



そして、数年後、あなたは反対の状況に陥る可能性があり、別の製品のアーキテクチャを説明するドキュメントはこれ以上良くなることはありません。もちろん、他の人も非常に悪いアーキテクチャを持っていることを知っておくと便利です。しかし、プロジェクトのサイズが数百万行のコードで測定され始め、開発者の数が数百行になると、アーキテクチャの必要性の問題は依然として重要になります。



ここでは、ワークフローのフレームワーク内で、さまざまなアーキテクチャ図が表示され始め、アーキテクチャ提案が機能について記述し始めます。これらすべてが議論、レビュー、検証、承認され、もちろん、これらのプロセスが終了する前でも時代遅れになります。そのような文書がアプリケーションコードの実際の構造を反映していると言う必要はありません。そして、実装に関しては、開発者がこれらのドキュメントをまったく読んでいないことがあります。または、書かれたものとはまったく異なる何かが実装されています。誰かが誰かを誤解したか、それをすることが急務であり、議論する時間がありませんでした。



多分すべてがそうあるべきである。たぶん、建築は、現実から切り離された投機的な文書を取り巻く事務局ですか？しかし、直感によれば、結局のところ、違います。では、「建築」とは何でしょうか。

アーキテクチャは...

「アーキテクチャとは」という質問をするとどうなりますか？10人のプロの開発者？ウィキペディアをこじ開けない場合、彼らは同じ答えを出しますか？



アーキテクチャは、一連の重要な決定であり、要素の構造とそのインターフェイス、および規定、ルール、合意のシステムであり、秩序を維持するアプローチ、グローバルな問題の解決策、相互作用による分解、システムとそのライフサイクルの高レベルの説明の両方です。パーツ、構造と動作のパターン、変更または削除が困難または費用がかかるもの、基本的な決定とトレードオフなど。



アーキテクチャは、アプリケーションがその目的を果たす方法でもあります。



APIはアーキテクチャであり、データスキーマもアーキテクチャであり、モジュールとサービスの構造です。アプリケーションスケーリングアーキテクチャ、アプリケーション信頼性アーキテクチャ、コンポーネント相互作用アーキテクチャ、およびセキュリティアーキテクチャがあります。そしてもちろん、各機能には独自のアーキテクチャがあります。そして、これらすべてが一緒になってアーキテクチャでもあります。



これはすべて、「アーキテクチャとは」という質問に対する答えと見なすことができますか？ -おそらくそうです。すべてが正しいようで、すべてが明確であるようです。しかし、この回答は実際に役立ちますか？実際のワークフローで使用できるものですか？あんまり。



決定が重要であるか基本的であるかをどうやって知るのですか？グローバルな課題は何ですか？高いまたは安いとはどういう意味ですか？複雑さをどのように推定しますか？高レベルと低レベルの境界はどこにありますか？注文とは何ですか？システムの目的は何ですか？



これらはすべて、あなたが答えることもできる質問です。定義を策定し、例を挙げて説明し、最悪の場合、意思決定プロセスを整理します。しかし、それでも、個人的な認識に応じて、物議を醸すもの、直感的なものが残り、すべての人が独自の方法で少し理解します。これは、異なる人々が同じ状況を根本的に異なる方法で解釈するという事実に基づいて、常に対立が存在することを意味します。開発者は、アーキテクトが実装の詳細を改ざんしている、アーキテクトが開発者がアーキテクチャを破っていると不平を言うでしょう。明確な境界がない場合、衝突は避けられません。



おそらく誰もがアーキテクチャとは何かについてある程度の一般的な理解を持っています。しかし、正式に検証され、数学的に正確な単一の定義に名前を付けることは困難です。



一方、「実現とは？」と聞くと-答えは明白である可能性が高いです：「ここにコードリポジトリへのリンクがあります！」そして、あなたはそれについて議論することはできません。そして、この答えの解釈には疑いや曖昧さはありません。 1 + 1 = 2、実装はコードです。



また、コードの操作は非常に簡単です。実装を理解したい場合は、開発環境でプロジェクトを開くことができます。コードの変更を確認する必要がある場合は、リポジトリにブランチがあります。アプリケーションの新しいバージョンをリリースするときが来たら、テストが開始されます。



もちろん、プロジェクトの構造は混乱を招く可能性があり、レビューの質は低く、テストの対象範囲は不完全です。しかし、少なくともコードを操作するときは、何をいつ行うかが常に明確です。



しかし、実装のように、アーキテクチャがコードで表現された場合はどうなるでしょうか。

多くの主流のプログラミング言語が現代の開発で使用されています。それらのほとんどはずっと前または非常にずっと前に現れました。そして、彼らはまだ良いですが、彼らは少し時代遅れになっています。これらは、弱く型付けされた言語：JavaScript、Python、PHP、Ruby、および強く型付けされた言語：Java、C / Objective-C / C ++、C＃です。それらは、同じプラットフォームのフレームワーク内で、構文上の砂糖をまき散らして、長年の問題を解決しようとする新しい言語に置き換えられていますが、グローバルに見ると根本的に新しい概念を導入することはありません：Swift、Kotlin、TypeScript、Go。これらはすべて、オブジェクト指向のパラダイムに基づいて構築された言語です。また、プログラミングへの機能的アプローチは成熟した人気を得ており、リストされた言語で実装され、特殊な言語で提示されていますが、あまり人気がありません：Erlang、F＃。実質的に新しい概念を実装する言語も人気を集め始めています：Rust、Haskell。



この多様性にはすべて共通点が1つあります。それは、すべて実装言語であるということです。これらのプログラミング言語はどれもアーキテクチャの表現ではありません。ただし、例外が1つあります。それはSQLです。



SQLは、宣言型である唯一の主流のプログラミング言語です。これは、リレーショナル代数モデルに基づいて構築されており、保存されたデータを処理するという狭い専門分野を持っています。しかし、それでも、なぜSQLをアーキテクチャの言語と見なすことができるのでしょうか。



まず、SQLはデータスキーマに関するメタ情報へのアクセスを提供します。データベースから、テーブル、列、関係、インデックス、ビュー、ロールなどのリストを簡単に取得できます。ストレージスキーマを文書化し、それを視覚化できることは、アプリケーションの構造を理解する上で非常に役立ちます。データスキーマ記述は、高レベルのアーキテクチャ記述の一種です。



次に、SQLは、クライアントがスキーマに記述されているデータの任意の組み合わせを照会できるようにするデータ照会言語を提供します。クエリ言語がない場合は、クライアントが必要とするデータモデルごとに、個別のAPIメソッドを実装するか、クライアントがデータスキーマのさまざまな部分に対して複数のAPI呼び出しを行い、必要なモデルをその側で組み合わせる必要があります。クエリ言語の存在により、アーキテクチャの説明から、一般的なスキームに従って特定のデータモデルを取得するためのAPIメソッドの列挙に関連する実装の詳細を除外することができます。クエリ言語は、アーキテクチャの説明から実装の詳細を除外します。



SQLは、アーキテクチャを説明するために重要な3つの主要なプロパティを提供します。

1. 宣言性-SQLを使用すると、アーキテクチャの説明をその実装から分離できます。
2. 分析可能性-SQLは、データスキーマのメタ情報へのアクセスを提供します。これにより、その表現を視覚化、文書化、および分析できます。
3. 正確性-SQLを使用すると、データモデルに制約を定義できます。これにより、実装によるさまざまなデータ整合性違反を防ぐことができます。

おそらく、SQLはデータストレージの観点からアーキテクチャを説明するためのツールと呼ぶことができますが、製品の完全なアーキテクチャを説明するには明らかに十分ではありません。

アーキテクチャを説明する他の手段

SQLの直接の類似物はGraphQLです。これにより、データスキーマを定義し、クエリ言語を介してデータスキーマにアクセスすることもできます。同時に、GraphQLは、リレーショナル代数モデルではなく、グラフ理論に基づいて構築されています。これにより、階層の操作が困難なSQLとは対照的に、より自然な方法で階層データモデルを操作できます。



GraphQLは、クライアントとサーバーの通信ソリューションとして宣伝されることがよくありますが、そのアプリケーションの領域はこれだけではありません。同様に、GraphQLを介して、サーバー間通信、さらにはサーバー間通信を提供できます。最新のデータベースはSQLインターフェイスのみを提供しますが、階層クエリを操作するための便利なAPIを提供しないという事実は、不快な省略です。



SQLがデータストレージスキーマのアーキテクチャを記述する手段である場合、GraphQLを使用すると、特定のアプリケーション領域の観点から、すでにビジネスレベルでデータスキーマのアーキテクチャを記述することができます。この意味で、GraphQLを使用すると、製品の実際のアプリケーション領域に近い、より高いレベルでアーキテクチャを定義できます。



コードモジュールとマイクロサービスは、それらのAPIと依存関係とともに、構造と関係の観点からアーキテクチャを表現するための手段でもあります。

アーキテクチャと実装

数十人の開発者が取り組んでいる小さなプロジェクトの場合、アーキテクチャの個別の説明は必要ないことがよくあります。プロジェクトコードがきちんと構造化されていれば、全体像と開発の方向性を理解するのに十分かもしれません。



プロジェクトが成長するにつれて、その一般的なアーキテクチャと新しいパーツの詳細および主要な改善の両方を説明するさまざまなドキュメントが表示されます。これは、数十人がプロジェクトに取り組んでいる場合、非常に実用的なアプローチです。



しかし、かなり大規模なプロジェクトの場合、開発者が数百人いると、このアプローチは失敗し始めます。ドキュメントが多すぎて、その内容が実装からますます分岐し始めています。誰もが同じように考えを表現することはますます難しくなっています。何十人もの人々のための集会は、多くのプライベートトピックを議論するために組織されていますが、本当に重要な変更は、まったく議論することなく実装できます。これはすべて、何かを提供しなければならない場合、フォローする場合、レビューする場合、さらには行う場合に、ますます多くのプロセスを編成する必要性につながります。官僚。その結果、開発者はより多くのドキュメントとより少ないコードを書き始めており、これは最も重大な問題ではありません。



もちろん、ビューロークラシー自体には何の問題もありません。どんな仕事でも、その組織は重要です。問題は、有用な仕事の単位あたりの事務局の量です。 1つを行うために、さらに2つ、3つ、4つ、5つのラリーを開催する必要がある場合、これはどこでも良くありません。



これは実装であるため、開発者が自分でどのような変更を加えることができるか、また、これはアーキテクチャであるため、レビューを要求する必要があるかどうかという単純な質問でさえ、問題を引き起こし始めます。さまざまなアーキテクチャのトリガーを考え出す必要があります。データスキーマを変更したり、暗号化やセキュリティの問題に触れたりした場合は、アーキテクチャを確認する必要があり、他のトピックはそうではないようですが、これは確かではありません。これはすべて、何百人もの開発者に策定して説明するだけでなく、説明されているルールに確実に従う必要があります。このようなプロセスは常に失敗します。



これらの問題はすべて、アーキテクチャの明確な定義の欠如に関連しています。



リポジトリ内の「.java」ファイルを変更すると実装の変更が明確に示されるのと同様に、「。architecture」ファイルを変更するとアーキテクチャの変更を示すことができます。もちろん、「。architecture」ファイルは自然界には存在しません。ただし、プロジェクトごとに、プロジェクトのどの特定の側面がそのアーキテクチャに関連しているかを定義し、明示的にすることができます。



データスキーマの変更がアーキテクチャの変更と見なされる場合、SQL移行を含むファイルはアーキテクチャを参照する必要があります。 APIもアーキテクチャの一部である場合は、同じスワッガーファイルの形式でAPIを定義し、それらに依存することができます。モジュールの構造がアーキテクチャである場合、モジュールの説明の変更はアーキテクチャの変更です。等。



アーキテクチャのすべての側面を標準的な方法で表現できるわけではありません。各プロジェクトには独自の詳細があります。たとえば、製品が特定の権利、役割、サブスクリプションの種類、アドオンなどのモデルを使用している場合は、製品のこの側面のアーキテクチャを適切な宣言形式で定義し、実装の詳細からアーキテクチャの本質を強調することを検討する必要があります。もちろん、そのような変更には大幅なコードのやり直しが必要になる場合があります。しかし、これは、ドキュメントでその権利モデルを説明しようとするよりも、製品アーキテクチャを定義する上で実質的に優れた投資です。



コードでアーキテクチャを正式に表現することは可能であり、これだけがアーキテクチャとは何かを明確に定義します。このビューを使用すると、アーキテクチャを分析して、常に最新のドキュメントを自動的に生成できます。残りのすべて：手作業で編集されたドキュメント、図、図-ビューロークラシー。



アーキテクチャはコード内で正式な表現を持つことができ、これだけがアーキテクチャと実装の間の明確な境界を定義します。そして、そのような境界線が必要です。

建築における工学的および進化的アプローチ

過去半世紀にわたって、開発業界は滝のモデルから反復的な開発へと長い道のりを歩んできました。そして今、業界はこの問題で行き過ぎているようです。ある場所では、建築家の仕事はもはやエンジニアや庭師の仕事に似ておらず、ベッドの除草のみを目的として雇われた季節労働者の仕事にますます似始めています。



エンジニアリングとクラフトを区別するのは、自然の法則、つまり、実験ではなく、計算と結論を出し、解決策を設計するための法則を理解することです。大工なら誰でも完全に受け入れられるスツールを作ることができますが、スツールを最適にするためには工学的な知識が必要です。軽く、信頼性が高く、安定していて、シンプルで安価に製造できます。エンジニアリングアプローチにより、最小限の労力で迅速に最適な結果を得ることができます。残念ながら、ソフトウェア開発では、エンジニアリングアプローチが常に可能であるとは限りません。



多くの場合、達成したい結果は非常に漠然と定義されており、ソリューションのアーキテクチャに大きな影響を与える多くの要因は不明であるか、まったくわかっていません。ソリューション自体の実装に関する作業は、アーキテクチャの詳細な詳細よりも高速で安価です。これが、開発への反復的なアプローチがそのような人気を獲得した理由の1つです。時には計り知れないほどです。



最悪の場合、アーキテクチャの開発は、各開発チームが単にアーキテクトに実装しようとしているものの説明のレビューを与えるという事実に要約できます。このような状況では、建築家の仕事は除草に還元されます。そして、ここであなたは忘れていませんか？これを考慮に入れましたか？そして、ここではそれは間違っています。ここにインデックスを追加しますか？そして、繰り返しの後に繰り返します。



雑草を取り除く必要があります。しかし、これだけを行うと、庭はどのようになりますか？花壇は果樹の木陰で枯れ、イチゴとニンジンが交互になり、これらすべてが無数の小道を横切り、利用可能なスペースを無駄にします。ここでアーキテクチャについて話すのは難しいです。



建築が現れるためには、建築家は少なくとも庭師の仕事をしなければなりません。ベリーと野菜は別々に栽培する必要があります-構造、そして人々が最も頻繁に行く場所-パスを敷設する必要があります-接続。アーキテクトは詳細を観察し、実現の過程で生じる特定の機能を単一の構造に編成および体系化して、積極的に行動することができます。ランドスケープデザインのように、アーキテクトはイベントの自然な流れを形作り、ポジティブなトレンドを強化し、ネガティブなトレンドを防ぐことができます。



そしてここでは、コード内のアーキテクチャの明確な定義が必要です。データスキーマ、モジュールとサービスの構造、それらのAPIと相互作用ルール。これらのツールを定義しないと、アーキテクトは実装レビューに行き詰まるか、開発者がそこにあるいくつかのドキュメントに記載されているルールに実際に従うことを素朴に望んでいますが、もちろんそれは起こりません。



アーキテクチャとその変更のルールの正式なプレゼンテーションがある場合、これはすでにアーキテクチャの開発への進化的アプローチと呼ぶことができます。そして、それは悪くありません。しかし、これに限定する必要がありますか？



はい、最初は要件があいまいに見え、要因があいまいに見え、システム自体が非常に複雑であるため、設計よりも実行が簡単です。しかし、時間が経つにつれて、これらのことが明らかになり始めます。アーキテクチャの開発における実際の経験により、そのアプリケーション領域の編成の詳細はますます明確になります。この一般的なソリューションは5つの異なる方法で実装されており、ユーザーはそのような多様性に苦しんでいることが明らかになります。いくつかのものは場違いで移動する必要がありますが、他のものはすでに古く、新しいソリューションに置き換えられているため、削除する必要があります。そして、新しい開発はそれほど新しく見えるのをやめます-そして私たちはすでにこれとそれを実装しました。これが何につながったのか覚えていますか？後でやり直す必要がないように、すぐにやりましょう。結局のところ、一度に正しく実行することは、通常、必要以上に高速です。しかし、これはあなたがそれを正しく行う方法を本当に知っている場合にのみです。そして経験を積むと、そのような理解がしばしばもたらされます。



優れたアーキテクチャは、それ自体が成長して少し組織化されたものではなく、全体的で対称的で有機的なものです。アーキテクチャの開発へのエンジニアリングアプローチは可能ですが、ルールとパターンを理解するだけでも時間がかかる場合があります。



特定のプロジェクトのアーキテクチャの正式な定義は、静的である必要はありません。非推奨のAPIメソッドは非推奨として宣言でき、欠落しているAPIメソッドは未実装として宣言できます。コードの意味のある部分は、別々のモジュールに配置するためにマークすることができます。テーブルを2つに分割するか、別のデータベースに移動することを計画できます。等。実装を変更せずにアーキテクチャを変更できます。実装は追いつくでしょう。また、より早く追いつくために、チームチャットで自動リマインダーを作成することにより、プロセスをわずかに自動化できます。同様に、Architecturalファイルで開発者が行った変更は、自動的にArchitectureチームのチャットに移動できます。



アーキテクチャの開発へのエンジニアリングアプローチが可能です。



同時に、建築家の仕事が開発者の仕事よりも根本的に良いか悪いかを想定するべきではありません。彼女はただ違う。開発者は、まず第一に、Imperativeスタイルで作業しますが、アーキテクトの作業はより宣言的です。アーキテクチャを理解するのが難しい場合がありますが、実装は日常的なものです。また、その逆も起こります。

アーキテクチャとデザイン

アーキテクチャとデザインという用語は、しばしば同じ意味で使用されます。あなたは言うことができます：システムアーキテクチャまたはシステム設計。概して、これが何であるかは明らかです。ただし、これらの用語には大きな違いがあります。



デザインとは、まず第一に、視覚的なもの、想像または見ることができるものを意味します。スキーム、図、モデル。デザインを使用すると、エンティティ間の関係、相互作用のトレースチェーンを視覚的に示し、構造の違いや類似性を確認できます。



ただし、アーキテクチャは視覚的なだけでなく、ルールと制約、推論、数学的な計算を含めることができます。視覚化が不十分な概念。



もちろん、両方とも重要です。



アーキテクチャの重要な側面がコードで明示的に定義されていると便利です。しかし、これだけでは十分ではありません。アーキテクチャを視覚化し、それに固有の原則を自動化することが重要です。



アーキテクチャにデータスキーマが含まれている場合は、それを視覚的に表現する必要があります。モジュールには依存関係があります-それらもレンダリングする必要があります。 APIがある場合は、サービスの構造に直接関連するドキュメントが必要です。等。デザインは、アーキテクチャを視覚的に表現したものです。



アーキテクチャに特定の原則がある場合、たとえば、「クライアントアプリケーションは特定のタイプのマイクロサービスにのみアクセスでき、すべてではない」など、通信モデルがある場合は、それらを自動的にチェックできます。同様に、マイクロサービスとデータベース間のリンクを制御できます。データモデルの設計に特定のルール、テーブルの命名に同じルールがある場合は、それらを自動的にチェックすることもできます。開発では、自動コードチェックが使用されます。アーキテクチャについても同じことができます。アーキテクチャで自動テストを作成できます。

結論

現代の開発者は、仕事を簡単にするために利用できる驚くべきツールを幅広く持っています。開発環境、ビルドシステム、さまざまなライブラリとフレームワーク、インフラストラクチャサービスとコンテナ。開発者はメモ帳でコードを記述しません。



アーキテクチャもコードであり、アーキテクチャを操作するために、実装を操作する場合と同じくらい強力で豊富なツールキットがあります。使用できるアーキテクチャツールはGoogleDocsだけではなく、最高のものとはほど遠いものです。もちろん、アーキテクトが現在利用できる既製のツールの範囲は、開発者ツールの範囲ほど広くはありません。そして、建築家が潜在的に使用できるすべてが箱から出して機能するわけではありません。それでも、物事はそれほど悪くはありません。



SQLのように、多くのツールが何十年も前から存在しているので、それらを正しく使用する方法を学ぶ必要があります。 GraphQLなどの新しいテクノロジーが注目を集め始めており、ビジネスドメインを記述するタスクが、ストレージドメインを記述するのと同じくらい日常的になることを期待しています。 Swaggerを含む、アプリケーション構造とAPIの文書化と視覚化のためのツールが利用可能です。実装をテストする場合と同じフレームワークと統合ツールを使用して、アーキテクチャをテストできます。



アーキテクチャ-宣言的。おそらく、文書を扱う事務局が建築家の仕事から完全に消えることは決してないでしょうが、すでにその量を大幅に減らすことができます。アーキテクチャもコードであり、時間の経過とともに、アーキテクチャで作業するために使用できるツールは、実装で作業するためのツールと同じくらい高度になる可能性があります。様子を見よう。



-

ドミトリーMamonov、

Wrike



PS私は、私は願って、私はかなり具体的な答えを与えることができた先の哲学的な質問のリストと記事を開始しました。少なくともそれが私の見解です。記事の中で何か役に立つものや新しいものを見つけましたか？あなた自身はこれらの質問にどのように答えますか？コメントを書いてください。