マイクロサービスの採用の成長は、いくつかの以前は見過ごされていたソフトウェア設計パターン。 これらのパターンの多くは、ソフトウェアアーキテクチャに関するものと同じくらいチーム構造に関する本であるEric EvansのDomain Driven Designから採掘されています。
そして、これらのパターンの中で、有界な文脈はおそらく理解することが最も重要です。 エンジニアとして，境界コンテキストをソフトウェアアーキテクチャ設計パターンと考えるようになった。 しかし、それは私たちが元の使用法から少しそれを選んだからです。 Evansが使用しているように、Bounded Contextは技術的なものと同じくらい組織的なパターンです。
そういうわけで、私は有界なコンテキストパターンをマイクロサービスを理解する上でのリンチピンとして見るようになりました。 それらを構築する方法だけでなく、実際に私たちが最初にそれらを構築する理由、そしてどのように彼らが私たちの組織をより成功させることがで 有界コンテキストが何であるかを理解すれば、技術的にも組織的にも有界コンテキストの考え方を採用すれば、マイクロサービスアーキテクチャの構築に真に成功することができます。
なぜマイクロサービスに移行するのですか？
まず、少し運動をしましょう。 自分自身にこの質問をしてください: なぜマイクロサービスを最初に構築するのですか？それについて考える時間を取る。
それについて考える時間を取る。
それについて考える時間を 最初に気になる利点は何ですか？ 私たちが解決することを望むべき主な問題は何ですか？ ちょうどあなた自身を正直保つためにある答えの下でメモしなさい。/p>
…
あなたの答えはありますか？ よし 自分自身に戻ってそれを読んでください。 標準的な技術的な利点に当ったか。 継続的な配信、スケーラビリティ、ポリグロット環境、コンテナとクラウド、そしてそのすべての良いもの？ すごいぞ！.しかし、あなたのトップの答えには、組織がより効率的に運営できるようにすることについて何かが含まれていましたか？ そうすべきだ マイクロサービスを構築することは技術的な利点を実現することではないからです。 本当に、それは組織の利益を得ることについてです。 他のすべては実装の詳細です。
Monoliths=結合されたコードと結合されたチーム
私たちのモノリスがますます大きくなるにつれて、生産性は衰え始めます。 そのための少なくとも二つの主要な理由があります。
私たちの速度にブレーキをかける
まず、すべてのエンジニアリングチームが一つの巨大なコードベースに貢献しています。 そのため、チームは自分のコードが他のコードと競合する可能性がますます高まっています。 これが引き起こす可能性のある潜在的な問題を軽減するために、コードのフリーズ、QAテスト期間、リリース列車などの手順を設定します。 -文字通り私たちの生産性を遅くするように設計されています。
もちろん、これらの手順は、機能や改善がタイムリーに展開されないようにします。 彼らはまた、チームの優先順位に集中するエンジニアの能力に大混乱をもたらします。 テスト期間中にバグが発見された場合、責任あるチームはコンテキストシフトし、そのバグの解決に焦点を当てる必要があります。 本番環境で深刻なバグが見つかった場合、チームはバグを修正するだけでなく、次のリリース列車で展開するためにフープを飛び越えなければなりません。
オンコール義務はboondoggleになります。 私たちのモノリスに何か問題が発生した場合、問題を解決するためには、昼夜を問わず誰かが利用可能である必要があります。 しかし、誰？ 大きなモノリスを持つ大規模な組織は、一般的に二つの選択肢に直面しています：
- 組織内の唯一の、悲しい、残念な仕事は、他のエンジニアのコードに
- 毎週、いくつかの任意のエンジニアが、いくつかの他のエンジニアによって書かれたコードによって最も可能性の高い問題を解決するための責任を負うという悲しい、残念な仕事を割り当てられる、回転オンコールスケジュール、いくつかの他のエンジニアリングチームで。
(Mis)私たちのチームを組織する
Monolithsは、さらに別の方法で私たちの組織を混乱させます。 私たちの組織全体は、同じ、大規模な製品に取り組んでいます。 しかし、我々はまだ組織を管理可能なチームに分割する必要があります。 だから私たちはチームの境界を見つけるために機能的な役割に目を向ける傾向があ:P>
残念ながら、この種の組織構造は制限されています共同作業。 手元にある真の問題を解決するために一緒に働くのではなく（例えば、機能Xをどのように設計、構築、および維持するのですか？）異なる機能領域のメンバーは、単に彼らが完了したときに比喩的にフェンスの上に自分の仕事を投げ、自分の部分に焦点を当てます。 チームの努力の結合された質が個々のチームメンバーの合計より大いに多くである共同および共同作用のための潜在性は失われる。また、ボトルネックが蔓延しています。
私達が機能区域によって私達のチームを組織するとき、それから私達は自然に優先順位のミスアラインメントを有する。 製品管理チームが、モノリスのチェックアウトプロセスを刷新する必要があると判断したとしましょう。 彼らはいくつかのモックをまとめるために設計チームとの時間をスケジュールします。 ある時点で、モックは終了し、実装するためにフロントエンドチームに渡されます。 もちろん、フロントエンドチームはバックエンドチームによって実装されるApiを必要とするため、それが完了するまでブロックされます。 バックエンドチームが新しいチェックアウトサービスの作業に優先順位を付けると、データベース管理(DBA)チームの助けが必要であることがわかります。 もちろん、それには独自の優先順位があります。 そのため、dbaが解放されるまでバックエンドチームはブロックされます。/div>
ところで、この組織構造は、不十分に設計された、過度に結合されたソフトウェアアーキテクチャのように少し思えます…そうではありませんか？
Microservices=分離されたコード、分離されたチーム
対照的に、microservicesアーキテクチャは、チームの自律性を可能にします。 自己完結型で、効率的に連携し、他のチームへの依存関係によって常にブロックされていないチームを形成することははるかに簡単になります。
チームは、設計から開発、展開まで、自分の仕事の完全な所有権を取ることができます。 各メンバーは、チームの目標を達成するための責任を共有するので、彼らは単に”自分の部分”以上のものに参加するようにインセンティブになります。 私は、プロダクトマネージャー、デザイナー、フロントエンド、バックエンド、モバイルエンジニアが一緒に製品の機能を設計するために得ているチームと協力してきました,一人で達成されている可能性よりもはるかに良い結果をもたらします.
チームは、本番環境にデプロイされると、独自の成果物に対する責任を獲得します。 これは一般的に、トラブルシューティングが容易な高品質のコードにつながります。 それはなぜですか？ モノリスとは異なり、チームは自分が所有するマイクロサービスの全体的なビューを持つ傾向があります。 そのため、チームは問題を予測し、問題が発生したときに問題をトラブルシューティングするための適切なロギングとメトリックを追加し、最初に問題を回避するための回復力パターン（再試行、サーキットブレーカ、フォールバックなど）を適切に使用する方がはるかに簡単です。
さらに、チームは自分の仕事に対する完全な所有権を持っているので、サービスを健全に保ち、本番環境で実行することは、悪夢のようなリリーススケジュール
最後に、チームは同じタイムライン上で同じ目標に向かって作業しています。 つまり、別の機能領域の誰かが解放されるのを待つので、一人の人をブロックすることはありません。私たちは自律性について意図的にする必要があります
しかし、モノリスをマイクロサービスに分割するだけでは、これらの利点を無料で得るこ マイクロサービスアーキテクチャの最初の素朴なビューを見てみましょう：
ほとんどのエンジニアのようなものであれば、マイクロサービスアーキテクチャの最初のアイデアは、まあ、マイクロサービスの束です。 それぞれが何らかのAPI（おそらくReST）を公開して、他のサービスがそこから読み取って書き込むことを可能にします。
経験を積むにつれて、すべてのマイクロサービスが同じ目的を果たすわけではないことがわかります。 したがって、モノリスがレイヤーに配置されていたのと同じように、マイクロサービスを配置します。
この時点で、構築するさまざまなタイプのマイクロサービスとアプリケーションを定義しました。 すごいぞ！. しかし、我々はまだチームの自律性の面で多くの進歩を遂げていません。 すべてのmicroserviceは、いくつかのチームが所有する必要があります。 どのチームがどのマイクロサービスを所有するのかという疑問が生じます。
クロスファンクショナルチーム
最初の素朴なアプローチは、モノリス組織構造を模倣してチームを編成することです。
div>
ここでは、uxデザイン、フロントエンドエンジニアリング、バックエンドエンジニアリング、データエンジニア、dba、qaなど、機能別に編成されたチーム（紫
これは、少なくとも最初は正しいと感じるかもしれません。 しかし、一歩後退して、私たちが顧客に提供しようとしている価値を見てみましょう。 それは私達の顧客のための次のような事を造る私達の目的であるか。
- データベーススキーマの束
- ユーザーインターフェイスのモックアップの束
- MySQLデータベースと話すことができるマイクロサービスの束？
そうではありません。 それらは私達が私達の顧客のための価値を作成するのに使用するちょうど用具である。 私たちがお客様/ユーザーに提供する実際の価値は、次のような機能と機能の形で提供されます:
- 検索する製品カタログ
- ショッピングカートにアイテムを配置し、その後、それらを購入するメカニズム
- 彼らの購入の状態を顧客に警告す むしろ、顧客のために作成する価値、つまり機能間、（適切な名前の）機能間のチームでチームを定義する必要があります。
クロスファンクショナルチームでは、誰もが最初から最後まで、特定の製品や機能を構築するために協力しています。 チームの誰もが同じ目標と優先順位を持っているので、機能領域は別の人によってブロックされません。 新しいバックエンドAPIサービスには、データベース設計作業が必要ですか？ チームのバックエンドエンジニアとDBAは、両方の作業を一緒に優先順位を付けることができます。
彼らの最高の状態で、クロス機能チームは、プロジェクトの各フェーズを通じて協力するメンバーを奨励します。 各チームメンバーは、機能の全体的な設計に貢献します。 フロントエンド、バックエンド、モバイルエンジニアが共同でAPI契約を定義します。 誰もがテストします。 そして皆は彼らの特定の範囲でよく精通されているようになり始める。したがって、チーム構造は次のようになります。
それは良いです。 しかし、何かがまだ右に感じていません。
確かに、私たちはおそらく製品を所有する上で、より効果的になるチームを形成しました。 しかし、私たちの組織が構築しようとしているマイクロサービスのトポロジを特定するために、トップダウンのアプローチを取ってきました。 私たちには、相互依存するマイクロサービスの大規模なコレクションが残されていますが、そのほとんどは一緒に結合されています。 私たちは、単に構築するために別のチームにそれらを割り当てました。これは、次のような懸念につながります。
- どのようにして、クライアントが持つ可能性のあるすべての現在および将来のニーズを満たすApiを作 サービスのいずれかが他のチームのサービスによって呼び出される可能性がある場合、データをカプセル化できますか？
- 他のチームが依存関係を実装するのを待つのにどれくらいの時間を無駄にしますか？
- 他のシステムの障害（カスケード障害）が原因でシステムの障害が発生する可能性がありますか？
- 私たちのサービスが関与する可能性のある呼び出しの数を制御することはできますか？ 私たちの組織がサービス間で無限の同期呼び出しを作成したり、天文学的な応答時間をもたらしたり、サービス間で無限に再帰的な呼び出しを行ったり
- 私たちのチームの特定の機能や問題空間が事前に計画されたマイクロサービストポロジに適していない場合はどうなりますか？
私たちはまだ別の考え方を必要としています。 おそらく、私たちが従うためのパターンはすでに存在しますか？
有界コンテキストを入力します
有界コンテキストは、ドメイン駆動設計、またはDDDから生まれたキーデザインパターンです。 境界のあるコンテキストを理解することは、自律チームを形成し、拡張によって自律的なマイクロサービスアーキテクチャを形成するのに役立ちます。
DDD自体は、組織内の個人が協力して共通言語を定義するソフトウェア開発の方法論を説明しています。 Eric Evans氏の著書「Domain Driven Design」では、製品所有者と協力して、製品、製品のコンポーネント、製品が実行できる(または製品で実行できる)アクション、ワークフローの一部などを記述するための合意された語彙を確立するエンジニアを頻繁に描写しています。 この語彙は、組織のドメインを網羅しています。しかし、多くの大規模な組織では、単一の一貫した語彙を定義することは実現不可能になります。
しかし、多くの大規模な組織では、単一の一貫した語彙 これらのケースでは、ドメインをサブドメインに分割します。 サブドメインの例には、次のものがあります:
- 在庫管理
- 製品発見
- 注文管理
- ショッピングカートとチェックアウト
デザイナー、エンジニア、プロダクトマネージャーなどは、サブドメインを構築するために一緒に取得するように、彼らは思考の独自の方法を形成し、サブドメインとそのコンポーネントについて話しています。
DDDは、機能横断的なチーム構造を満たしている場所です。 チームメンバーは異なる機能領域から来ていますが、彼らは自分のサブドメインを担当し、最終的には常駐の専門家になります。 さらに、チームは、サブドメインを実現し、組織の顧客に提供するために必要な成果物（マイクロサービス、webアプリケーション、モバイルアプリ、データベース、およ
チームとその成果物は、境界のあるコンテキストを含むと考えることができます。
有界コンテキストの定義
Evansは彼の本の中で有界コンテキストについて頻繁に議論していますが、彼は実際にパターンを明示的に定義してい だから私はここでそれをやろうとします：
有界コンテキスト:
システムに入ることができるものとそれを出ることができるものを仲介する慎重に設計された境界を持つ内部的に一貫したシステム。
言い換えれば、有界コンテキストは、システムに入ることができるものとそれを出ることができるものを支配する明確に定義された境界を持つコンテキスト—本質的には、協調コンポーネントをカプセル化するシステムを表します。P>
セル（総称してすべてを構成するもの生き物）素敵な類推を提供しています。 細胞内には、すべての細胞自体の中にカプセル化されているあらゆる種類のコンポーネント（核、リボソーム、細胞質、細胞骨格など）があります。 しかし、各細胞を取り囲むのは膜であり、細胞の内部と生物の残りの部分との間の障壁として作用する。 膜は、その環境から細胞を保護し、特定の栄養素がそれに入ることを可能にし、そして様々な副産物が去ることを可能にする。
同じように、有界コンテキストはさまざまなコンポーネント(マイクロサービス、webアプリケーション、モバイルアプリ、データベース、メッセージキューなど)で構成されています。 また、これらのコンポーネントをカプセル化する論理的障壁としても機能します。 内部的には、コンポーネントを結合することができ、相互にデータを自由に渡すことができます。 しかし、有界コンテキストは、外部的に疎結合を強制し、明示的な点を定義するのに役立ちます:
- 外部データを入力することができます（おそらくkafkaトピックを購読しているコンシューマーを介して）
- 内部データを終了することができます（別のKafkaトピ チームは、さまざまなチームメンバー（デザイナー、フロントエンド/バックエンド/モバイルエンジニア、プロダクトマネージャー、データエ 内部的には、これらのメンバーは同じ一貫した目的の方に協力して働く。 さらに、これらのチームメンバーは、他のチームへの依存関係を最小限に抑えるようにカプセル化されています（またはすべきです）。
そのため、組織レベルで開始し、構築するすべてのアプリケーションとマイクロサービスを定義するのではなく、サブドメインの周りにチームを構築し、それらのチームがサブドメインを成長させ、構築する必要があるものを定義できるようにします。 適切に行われると、組織内のさまざまな境界のあるコンテキストは、剛性のある事前定義された構造ではなく、有機的に成長する傾向があります。
モノリスを破る上での影響
コンウェイの法則は、組織が組織の通信構造を模倣したソフトウェアシステムを設計することを示しています。 それはしばしば真実であることが証明されているので、マイクロサービスの構築を開始するときに組織をどのように構造化するかについて確かに、今では、絵があなたの心の中に浮上する必要があります。
モノリスからマイクロサービスに移行すると、水平に（モノリスをその機能層で分割する）のではなく、垂直に（モノリスをそのサブドメインで分割する）div>
我々は左に行うように物事を分割する必要がありますが、我々は上に行うように右 言い換えると、モノリスのデータアクセスレイヤーをデータマイクロサービスに置き換えることから始めるべきではありません。 むしろ、我々は（そのようなチェックアウトプロセス、またはおそらく製品検索など）全体の機能を分割することによって開始する必要があります。 各フィーチャは、境界のあるコンテキストを表します。 そして、それぞれは、専用のクロス機能チームによって分割されます。
さらに、そのチームは手元のタスクに焦点を当てる必要があります。
- 既存の機能を忠実に複製するか、
- または（より良い）顧客のために全く新し
プロセスの一環として、チームは努力に最も適したシステムを設計する必要があります。
たとえば、モノリスから製品検索機能を削除することを決定する場合があります。 製品検索チームは、最終的に以下を含むシステムを設計する可能性があります:
- カフカの消費者は、製品の独自の内部レコードシステム（SoR）を更新するために、外部のカフカのトピックの数に耳を傾けます。
- SoRへの変更を内部のKafkaトピックにプッシュするKafkaパブリッシャー
- その内部トピックをリッスンし、Elastic Searchインデックスを更新する別のKafkaコンシューマ
- Elastic Searchを照会するフリーフォーム検索用のGraphQLエンドポイント
- IDで個々の製品を取得するReSTエンドポイント
- これらのエンドポイントを使用して、顧客が製品を検索し、製品の詳細を探索できるようにする再設計されたwebアプリケーション
- これらのエンドポイントを使用するモバイルアプリ
- メッセージをプッシュするkafkaパブリッシャ, 顧客が外部のKafkaトピックに対して実行する個別のクエリを表し、興味のある他の境界コンテキスト（分析など）で使用します。
私たちの製品のデザイン-赤でカプセル化された境界コンテキストを検索すると、次のようになるかもしれません
私たちのモノリスのより多くの垂直部分を剥がし始めると、他のチームは独自の境界コンテキストを構築します。 これらの境界のあるコンテキストは、お互いにかなり異なって見えるかもしれません。div>
各チームは、手元のタスクを解決するための最良のビルド方法を決定します 与えられた有界コンテキスト内のコンポーネントが密に結合されている可能性があることに注意してください。 この例では、境界のあるコンテキスト間の通信は、Kafkaメッセージキューを介してメッセージを渡すことによって行われます。 重要なのは、境界のあるコンテキスト間の同期要求/応答呼び出しを回避していることです。
これは、モノリスの残っているものにも当てはまります。 私たちは確かに私たちの新しいマイクロサービスと私たちのレガシーモノリスとの間の緊密な結合を望んでいません。 そのため、モノリスの一部を剥がすと、メッセージパッシングを利用して、残りの部分が新しい境界のあるコンテキストと通信できるようにします。
このデカップリングのすべてのリアリティチェック
この時点で、私たちは境界のあるコンテキストをデカップリングし続けることが本当に可能であるかどうかを自問するかもしれません。
現実の世界では、実際にチームを外部の依存から保護することはできますか？ チームが自分の仕事を成し遂げるために別のチームによってブロックされなければならない場合はありませんか？
そして、他のサブドメインから完全に分離されたサブドメインのサービスアーキテクチャを実際に作成できますか？ ある境界のあるコンテキストのアプリケーションが、別のサービスを同期的に呼び出す必要は本当にありませんか？実際には、境界のあるコンテキストを100％分離しておくことは不可能かもしれません。
実際には、境界のあるコンテキストを100％分離しておくこ しかし、私たちは、私たちのほとんどが考えるかもしれないよりもはるかに近い、近くに取得することができます。
実際のアーキテクチャ
まず、デカップリングアーキテクチャを見てみましょう。 多くの場合、私たちは、任意のタイプのデータが正確に1つの場所に存在する必要があり、他のシステムがデータにアクセスするためにその1つの場所を直接呼び出さなければならないという誤った考えを買います。これは、データに単一の真実のソース（SSoT）を割り当てることと呼ばれます。
これは、データに単一の真実のソース（SSoT）を割り当てることと呼ばれます。
しかし、SSoTsの考え方を解剖するこの記事で説明したように、その概念は全体として反パターンです。 代わりに、ほとんどの境界コンテキストでは、使用する必要があるデータの独自のローカルコピーを格納する必要があります。
これは、前のセクションのProduct-Search Bounded Contextによって例示されています。 この限定されたコンテキストは、もちろん、私たちの組織の製品カタログデータに大きく依存しています。 しかし、確率は、そのデータは別の有界コンテキストで生成されます（これをProduct-Entry Bounded Contextと呼びます）。
最初の（素朴な）アプローチは、Product-Entry Bounded ContextからReST APIを公開し、Product-Search Bounded Context内のサービスにそのAPIを呼び出すように強制することです。 しかし、我々はより良いことができます。 代わりに、製品入力サービスによって行われた変更をKafkaに公開することで、システムを分離したままにすることができます。 私たちの製品検索カフカの消費者は、それらのメッセージをピックアップし、製品検索データベースを更新します。/div>これらの2つの有界コンテキストは、最終的には一貫性があります。 これは、特定のデータがProduct-EntryとProduct-Searchの間で矛盾する可能性がある短い期間があることを意味します。 たとえば、ホワイトウォンバットウィジェットの価格がraised1.99から2 2に上昇した場合。49,短い期間があるでしょう(ミリ秒ではない場合は、多くの場合、秒の問題)どこにあります50¢二つの境界のコンテキストにわたって白いウォンバット
これは、境界のあるコンテキストを結合する以外に代替手段がない現実世界のケースにつながります。 場合によっては、最終的な一貫性が許容されない場合があります。 たとえば、お客様がオンライン購入を完了する前に、ショッピングカート内のすべてのアイテムが実際にその時点で利用可能であることを確認する必 その場合でも、2つの有界コンテキスト間の結合を最小限に抑えることができます。
私たちのやりとりは次のようになります。
- 顧客がProduct-Search UIを使用して製品を検索すると、Product-Searchデータベースが情報（スタイル、カスタマーレビュー、価格設定など）を取得するために使用されます。)製品について
- 顧客がチェックアウトプロセスを開始しても、表示する必要がある情報を取得するために製品検索データベースを使用します。
- 最後に、顧客がその最終的な”購入完了”ボタンをクリックすると、購入を完了する前にアイテムの可用性を検証するために、Product-Entry Boundedコンテキストへ
承認に関連する即時の一貫性を必要とする別の一般的な例。 多くのシステムでは、要求ごとにセキュリティトークンを取得または検証する必要があります。 そのような場合には、境界コンテキストが別のセキュリティ指向の境界コンテキストを呼び出すことを許可する必要があります。
実際の組織構造
自己完結型のクロスファンクショナルチームはどうですか？ 彼らは現実の世界でどのように可能ですか？実際には、それは完全に自立したチームに向かって継続的な動きのプロセスです。
実際には、それは完全に自立したチームに向かって継続的な動き まれに私達は私達のチームとの100%の自主性に達しない。 しかし、チームをインテリジェントに組織化し、発生するボトルネックを認識して対応することから始めると、私たちは近づくことができます。
まず、垂直方向の機能横断チームを最大化し、水平方向の単一機能チームの数を最小限に抑える必要があります。 それは、他の製品指向のチームが消費する共通のデータサービスを構築することを使命とする、いわゆる”コア”チームを形成する衝動に抵抗し、代わりに彼らが提
多くの組織は、最初の製品マネージャー、およびフロントエンドとバックエンドエンジニアのドメイン指向のチームを形成し、この目標に向かってつま先。 それはスタートです。 しかし、他に誰がこれらのチームを含める必要がありますか？ 正確なメンバーシップは、ニーズの異なるチーム間で異なる場合があります。 しかし、我々はのようなものを考慮する必要があります:
- 私たちのチームにフロントエンドエンジニアがいる場合、ドメインに専念しているグラフィックデザイナーと緊密に協力する必要があります。
- モバイルエンジニアは、多くの場合、組織の独自の領域に隔離されていますが、モバイルコンポーネントを持つドメインに含める必要があります。
- データメッシュに関する彼女の啓発的な記事では、Zhamak Dehghaniは、データエンジニアがクロスファンクショナルチームから除外されることが多いことを嘆いて
チームのメンバーを決定したら、ボトルネックに注意する必要があります。 私たちの機能横断的なチームの生産性を習慣的にブロックする他のチームはありますか？
たとえば、多くの組織には専用のセキュリティチームがあります。 組織には、一貫性のあるセキュリティ戦略と、その戦略に対するガバナンスを確保する方法が必要です。 ただし、チームが作業のセキュリティレビューを可能にするために、さまざまな段階で作業を停止することも一般的です。 最高の状況であっても、これは日常的なビジネス慣行として私たちのチームのための障害物を確立します。 さらに、満たされていなかったセキュリティ要件を明らかにするため、チームは作業の全部または一部を破棄してやり直す必要があります。これは明らかに悪い臭いです。
これは明らかに悪い臭いです。
しかし、どのようにして組織のセキュリティ標準を強制しながら、チームが自律的で生産的なままにすることができますか？
機能横断チームにセキュリティエンジニアを追加することで、これを行うことができます。 私たちが取ることができる3つのアプローチがあります:比較的大規模なセキュリティチームを持つのに十分な運が良ければ、各機能横断チームにフルタイムのセキュリティエンジニア（SE）を割り当てることがで
- 小規模なセキュリティチームでは、各SEを複数の機能横断チームにパートタイムで割り当てることができます。 これにより、SEsはチームの目的と設計を理解し、チームと協力してプロセス全体を通して組織のセキュリティ基準を遵守することができます。
- どちらかに十分なセキュリティリソースがない場合は、反対の方向に移動できます。 セキュリティチームのメンバーを機能横断チームに連れて行くのではなく、機能横断チームのメンバーをセキュリティチームに連れて行くことができます。 各機能横断チームは、1人または2人のセキュリティ担当者を指名します。 代表者は、定期的にセキュリティを満たし、組織のセキュリティ要件と基準に遅れないようにします。 彼らは、セキュリティの専門家自身ではないかもしれません。 しかし、彼らはセキュリティエンジニアの役割を果たすことができ、チームが組織のセキュリティ慣行を遵守することを保証します。
ギルド
これは、牽引力を得ている別の組織パターンに入ります：ギルド。 ギルドモデルは、機能横断的なチームモデルから生まれました。 その性質上、これらのチームにはさまざまな機能を専門とするメンバーが住んでいます。 しかし、それは多くの場合、同様に一緒に会うために、特定の機能に特化した人々のために理にかなっています。:
- 自分のスキルを磨くとお互いから学ぶ
- 発見し、その特定の機能のためのベストプラクティスを確立
- 機能に応じて、会社の標準と要件を作成
私たちの最後のセキュリティソリューションは、効果的に”セキュリティギルド”を形成しました。 チームメンバーは主に垂直チームと協力していましたが、定期的にセキュリティ”ギルド”に会い、組織のセキュリティ慣行と標準について議論しました。
ギルドモデルは、ソフトウェアアーキテクチャに関しては特にうまく機能します。 特にマイクロサービスアーキテクチャでは、ある程度のレベルの組織全体の技術ガバナンスが必要です。 しかし、比喩的な象牙の塔に座って、チームにルールを配っている建築家のグループを持つことは、一般的に逆効果です。 代わりに、私たちのクロスファンクションチームのシニア/リードエンジニアは、定期的に建築ギルドで会うことができます。 そこでは、彼らはチームから問題を提起し、解決策を解決し、パテンと基準を確立することができます。
ギルドは、他のほぼすべての関数にも拡張できます。 結局のところ、私たちはデザイナーが共通のUIスタイルガイドを開発し、そこから作業することを望んでいます。 フロントエンドエンジニアが同じUI要素を使用するようにします。 QAエンジニアは、私たちの組織でのテストの実施方法に合わせて調整する必要があります。 また、製品管理者は、組織の全体的な製品ロードマップと同期する必要があります。
Bring it all together
マイクロサービスへの移行は、チームの生産性を劇的に向上させることができます。 しかし、私たちはそこに私たちを得るためにマイクロサービスアーキテクチャを利用する方法を理解する必要があります。 マイクロサービスに関連するすべての設計パターンと概念のうち、境界のあるコンテキストは、おそらくその理解を与えるための最も重要なものです。
有界な文脈をしっかり把握して、我々はそれを理解しています:
- 私たちの組織構造と私たちの技術アーキテクチャは手をつないで行く
- 私たちの製品指向のチームは、彼らが構築するシステムが他のシステムから分離されるべきであるのと同じように、他のチームへの最小限の依存関係を持つべきです
一般的に、境界のあるコンテキストを受け入れることは、私たちのマイクロサービスアーキテクチャで成功する必要があるという考え方に置きます。 マイクロサービスの旅に出る前に、この重要なパターンを理解してください。
