私はすぐに言います-私はシステム管理からこの技術を再訓練している初心者の建築家です。
この記事では、次のトピックについては説明しません。
- 業界に参入した経緯とシステム管理の問題。
- 健全な文学や記事の存在/不在、システムアーキテクトの学校;
- 新しい立場でどのように感じているか、将来の計画など。
導入部分は、大企業の建築家の場所についての私の限られた理解から始まります。
IT部門には、さまざまな方向のプログラマー、アナリスト、テスター、システム管理者、さまざまなレベルの技術サポートなど、メンテナンスおよびソフトウェア開発プロセスに多くの参加者がいます。 それぞれがシステムの一部またはシステム全体を見ますが、その観点からは（たとえば、第1レベルのテクニカルサポートスペシャリストは上級ユーザーとしてシステムを「見る」）。
ちょっとした哲学。 企業のすべての情報資産（アプリケーション、データベース、リポジトリ、データソース、統合サービス）は単一のエンティティです。 現代の企業には完全に自律的なサービスがありません。 企業のサービスと相互作用しない資産からは、将来的に統合が必要になります。
したがって、このすべての論理とデータのボイラーのアーキテクトには、特別なものが必要です。それは、情報システムのアーキテクチャビジョンです。 建築家とは、ほとんどすべてを知っている人です。 いいえ、彼がコードに入り込んでバグを修正できるというわけではありません。 私はデータとそれらの間の関係の観点から「ビジョン」を意味します。 情報システムの統合は現在、アーキテクチャの最も複雑で重要なタスクです。 すべての家はすでに建設されています-企業は、多くの場合、自作のシステムよりも購入したシステムを好みます。 はい、彼らは建物の化粧品の修理を行いますが、これは最も重要なことではありません。 （ソフトウェア会社で働いていない場合）。 アーキテクトの主なタスクは、コミュニケーションを構築し、インフラストラクチャを構築することです。
しかし、ほとんどの場合、会社は孤立した環境に住んでいません。 単一の高速道路が通じない、優れたインフラストラクチャを備えた都市では意味がありますか？ 同社は、さまざまな組織や個人のITシステムと直接または仲介者とやり取りします。 このようなやり取りを組織することは、交換の主題と形式についてシステムのすべての参加者に同意する必要があるため、何倍も困難です。 問題は、これらの合意に既に達し、国際標準で規定されているという事実によって簡素化されるかもしれませんが、実際には、それらに固執する人はほとんどいません。
「装飾」について少し説明します。 私たちの都市にはすでに内部および外部のインフラストラクチャがあります-人々だけが都市に住んでいないなら、他に必要と思われるもの。 そして人々は、アパートの改修から新しい建物の建設まで、常に新しいニーズを抱えています。 そのため、新しい要件の継続的な流れが非常に普通であるのはITです。 アーキテクトのタスクは、要件とその実装をトレースし、実装の決定に影響を与えることです。 いずれかのアパートの壁を取り壊して建物全体を破壊したり、誰も必要としない家を建てたりしてはなりません。
開発者がユーザーの要件を満たさない製品をリリースする場合があります。 そして、ここでは不愉快ですが、アーキテクトの主なタスクの1つが登場します。これは、プログラムコードにユーザー要件を実装するプロセスを追跡することです。 アーキテクトは、決定だけでなく、これらの決定を行う理由も理解し、文書化する必要があります。
前の段落から、工芸システム設計者と都市計画者の主な違いが続きます。 準備はいい？ 簡単な真実をお伝えします-物理法則はソフトウェアのアーキテクチャに影響しません！ いいえ、もちろん、システム上の制限、ベストプラクティス、パターン、および原則があります。 しかし、これはすべて簡単に回避でき、石と砂の両方から家を建てることができ、両方とも何百年も続きます。 パイプラインを地球のコアに通したり、家を上下逆さまにしたりすることができます。決定がバランスが取れていれば、すべてが完璧に機能します。 情報資産は、ある意味では現実的ではなく、開発者の空想上の飛行に制限はありません（当然、合理的な制限内です）。
開発者の想像力を制限する方法の1つは、アーキテクチャの原則と制限です。 これらは、システムおよびビジネスレベルのルールのセットです。 たとえば、原則の1つは次のようになります。「プロジェクトではASP.Netテクノロジを使用します」。 これらの原則の理由をすぐに書くことは悪くありません。
当然、上記のすべてを2つの場所に保存する必要があります。アーキテクトの頭の中に簡単に、ドキュメントに詳細に。 ドキュメンテーションは、上記のすべてよりも重要で複雑なタスクです。 アーキテクチャ文書自体は、詳細に関しては、要件とソースコードの間のどこかにある必要があります。 このドキュメントは、ユーザー要件がサブシステムにどのように変換されるかについてのちょっとした話です。
ドキュメントアーキテクチャの難しさの1つは、頻繁な変更です。 また、これらの変更の履歴を監視および維持するための明確な方法論はありません。 また、このドキュメントを維持するための原則についても理解していませんが、私のサイクルの3番目または4番目の記事でそれらを開示しようとします。
今日は以上です。 あまりにも大きな記事を書くのではなく、すべてを小さな部分に分割することにしました（ちなみに、これもアーキテクトのタスクの1つです）。 次の記事では、建築家の言語-UMLと抽象化について話します。
更新 トピックについてコメントをお願いします。 私の能力のレベルを評価する必要はありません。