建築設計の観点から見ると、ほとんどの試みを小さな領域にカプセル化するように努めるべきです。現時点では、複数のビジネスの試みが時間の経過とともに混乱を引き起こしたり、技術システムの外部適応性を低下させたりすることはありません。これを行うには、次のアーキテクチャ原則が非常に重要です。
まず、単一責任とは、各ビジネスの試みを可能な限り単一のモジュールにカプセル化することを指します。利点は、試行が失敗すると、ビジネス ロジックをすぐにオフラインにして、全体の複雑さへの影響を回避できることです。
90% の場合、ビジネスの試みは期待どおりにはいきません。この場合、単一責任の設計に準拠すると、古いロジックを簡単にオフラインにすることができます。これは非常に重要で、自分が混乱を引き継いだとき、無効なロジックをログオフしない先輩を憎む必要があります。たとえば、オフラインにならないという失敗ロジックは、トイレの水を流さない行為と同じです。
2 番目に、依存性を最小限に抑えるとは、ほとんどのビジネスの試みがビジネス層で完了できるようにするための全体的なアーキテクチャ設計を指します。各ビジネス側のニーズが基礎となるロジックに侵入する場合、すべての試みはチーム間の協力となり、このアーキテクチャではビジネスの試みの速度が大幅に低下します。
第三に、最小限のデータ共有。影響範囲を最小限に抑えるために、他のビジネス モジュールとのデータ交換、特に出力を最小限に抑えようとしている企業。そうしないと、このビジネスの試みのデータ モデルが他のビジネスを汚染し、試みが失敗した後の他のビジネスへの影響を区別することが困難になります。
4 番目に、最小限の公開とは、API、データ共有、イベント、メッセージ フローなど、外部の世界に影響を与えるすべての通信メカニズムを含め、ビジネス試用期間中にインターフェイスが部門または企業の外部に公開されないことを意味します。
戦略レベルのプロジェクトは全社レベルで明確である必要があり、十分な期間にわたって継続される必要があります。
ほとんどの場合、保存技術システムの長期的な外部適応性は、当面のニーズの実現と同じくらい、あるいはそれ以上に重要です。
もちろん、技術職の供給圧力による技術人材の安定性の低さや近視眼的な設計の問題にも言及した。この問題を軽減するために、アーキテクトは次のことを行うことができます。
まず、パッケージング機能の重要性に対する認識を向上させます。ビジネスの試みを効果的にカプセル化する能力が必要であること、そしてこの能力は最終的にはテクノロジーの外部適応性を向上させる能力に変わるということを、すべての技術系学生が理解できるように支援する必要があります。これは技術者の基本スキルであり、コードを書いた初日から必要となります。ただ、キャリアが進むにつれて、コード ロジックのカプセル化からビジネス ロジックのカプセル化、そして最終的にはビジネスの試みのカプセル化に移行します。プログラマーが日常業務において能力トレーニングのこの側面を無視するのは、実際には賢明ではありません。
次に、複雑さの制御メカニズムを構築します。ここでは設計レビューが鍵となります。ビジネスの試みには設計レビューも必要ですが、そのレビューの固定部分は、ロジック、データ、インターフェイスの最小爆発半径の設計です。
第三に、必要最小限の構造の原則を実現します。オッカムの剃刀の原則を全社に導入します。機能を追加したり複雑さを導入した設計には正式なレビューが必要ですが、簡素化にはその必要はありません。
アーキテクトのビジネス理解力は、ビジネスを深く理解した上で自らの技術的洞察に基づき、その技術的洞察を活用して事業開発を推進します。
この記事は6月の3日目の学習メモです 内容はGeek Timeの「郭東梅の建築講座」から引用しています この講座はオススメです。