当初は一枚岩がありました。ビジネスに干渉することなくアーキテクチャを変更する方法です。

こんにちは！私の名前はイゴール・ナラジンです。デリバリークラブのロジスティクスチームのチームリーダーです。アーキテクチャを構築および変換する方法と、それが開発プロセスにどのように影響するかを説明したいと思います。



現在、Delivery Club（およびフードテック市場全体）は非常に急速に成長しており、技術チームにとって非常に多くの課題を生み出しています。これは、次の2つの最も重要な基準で要約できます。

• プラットフォームのすべての部分の高い安定性と可用性を確保する必要があります。
• 同時に、新機能の開発のペースを速くしてください。

これらの2つの問題は相互に排他的であるように思われます。プラットフォームを変換して、完了するまで新しい変更をできるだけ少なくしようとするか、システムを大幅に変更せずに新しい機能を迅速に開発します。



しかし、（これまでのところ）両方とも成功しています。これをどのように行うかについては、さらに説明します。



まず、プラットフォームについて説明します。絶えず増大するデータ量、サービスに適用する基準、およびその過程で直面する問題を考慮して、プラットフォームをどのように変換するかについて説明します。



次に、プラットフォームの変更と競合することなく、システムを不必要に劣化させることなく、機能を提供するという問題をどのように解決するかを共有します。 プラットフォームから始めましょう。

初めは一枚岩がありました

Delivery Clubコードの最初の行は11年前に作成されたもので、このジャンルの最高の伝統では、アーキテクチャはPHPのモノリスでした。モノリシックアーキテクチャの古典的な問題に直面するまで、7年間、それはますます多くの機能で満たされていました。



最初は、完全に満足していました。保守、テスト、および展開が簡単でした。そして、彼は問題なく初期負荷に対処しました。しかし、通常の場合と同様に、ある時点で、モノリスが非常に危険なボトルネックになるほどの成長率に達しました。

• モノリスの障害や問題は、すべてのプロセスに完全に影響します。
• モノリスは、変更できない特定のスタックにしっかりと結び付けられています。
• 開発チームの成長を考慮すると、変更を加えることが難しくなります。コンポーネントの接続性が高いため、機能を迅速に提供できません。
• モノリスは柔軟にスケーリングできません。

これは私たちを（驚きの）マイクロサービスアーキテクチャに導きました-その長所と短所について多くのことが言われ、書かれてきました。主なことは、それが私たちの主な問題の1つを解決し、システム全体の最大の可用性と障害耐性を達成できるようにすることです。この記事ではこれについて詳しく説明しませんが、代わりに、どのように実行したのか、そしてその理由を例を挙げて説明します。



私たちの主な問題は、モノリスコードベースのサイズとその中のチームの不十分な専門知識でした（プラットフォームは私たちが古いと呼んでいるものです）。もちろん、最初は問題を完全に解決するためにモノリスを取り、カットしたかっただけです。しかし、1年以上かかること、そしてそこで行われている変更の数がこれを終わらせることは決してできないことにすぐに気づきました。



したがって、私たちは別の道を歩みました。それをそのままにして、残りのサービスをモノリスの周りに構築することにしました。これは、注文処理ロジックとデータマスターの主要なポイントであり続けますが、他のサービスのデータのストリーミングを開始します。

エコシステム

Andrey Evsyukovが私たちのチームに関する記事で述べたように、ドメイン領域の主な領域であるR＆D、ロジスティクス、コンシューマー、ベンダー、内部、プラットフォームに焦点を当てました。これらの領域内で、サービスが機能する主なドメイン領域はすでに集中しています。たとえば、ロジスティクスの場合、これらは宅配便業者と注文であり、ベンダーの場合はレストランと役職です。



次に、より高いレベルに上昇し、プラットフォームを中心にサービスのエコシステムを構築する必要があります。注文処理が中心であり、データマスターであり、残りのサービスはその周りに構築されます。同時に、方向性を自律的にすることが重要です。一部が失敗しても、残りは機能し続けます。



低負荷では、必要なエコシステムの構築は非常に簡単です。処理プロセスとデータの保存、および紹介サービスが必要に応じてそれらに適用されます。



低負荷、同期要求、すべてがうまく機能します。



最初の段階では、まさにそれを実行しました。ほとんどのサービスは、同期HTTP要求で相互に通信しました。一定の負荷の下では、これは許容されましたが、プロジェクトとサービスの数が増えるほど、問題は大きくなりました。





高負荷、同期要求：完全に異なるドメインのユーザー（宅配便業者）でさえ、誰もが苦しんでいます。



指示内でサービスを自律化することはさらに困難です。たとえば、ロジスティクスの負荷が増加しても、システムの他の部分に影響を与えることはありません。同期要求がいくつあっても、これは解決できない問題です。明らかに、同期要求を破棄して非同期通信に移行する必要がありました。

データバス

したがって、同期モードでデータにアクセスするという多くのボトルネックが発生しました。これらの場所は、負荷の増加という点で非常に危険でした。



これが例です。デリバリークラブを通じて少なくとも一度注文した人は、宅配便業者が注文を受け取った後、カードが表示されることを知っています。その上で、あなたはリアルタイムで宅配便の動きを追跡することができます。この機能には、いくつかのマイクロサービスが含まれます。主なものは次のとおりです。

• mobile-gatewayこれは、モバイルアプリケーションのフロントエンドのバックエンドです。
• courier-tracker、座標の送受信のロジックを格納します。
• logistics-couriersこれらの座標を格納します。それらは、宅配便のモバイルアプリケーションから送信されます。

元のスキームでは、これはすべて同期して機能しました。1分に1回のモバイルアプリケーションからの要求は、座標にアクセスして受信mobile-gatewayするサービスに送られました。もちろん、このスキームでは、それはそれほど単純ではありませんでしたが、最終的には単純な結論に要約されます。アクティブな注文が多いほど、受け取った座標の要求が多くなります。 私たちの成長は時々予測不可能であり、そして最も重要なことに、そのような計画が失敗する前の時間の問題です。これは、非同期相互作用のプロセスをやり直す必要があることを意味します。つまり、座標の要求を可能な限り安価にするためです。これを行うには、データストリームを変換する必要があります。courier-trackerlogistics-courierslogistics-couriers

輸送

サービス間の通信を含め、すでにRabbitMQを使用しています。しかし、主要な輸送モードとして、すでに実績のあるツールであるApacheKafkaを採用しました。それについては別の詳細な記事を書きますが、それをどのように使用するかについて簡単に説明したいと思います。



Kafkaをトランスポートとして最初に実装し始めたとき、私たちはそれをそのままの形で使用し、ブローカーに直接接続してメッセージを送信しました。このアプローチにより、戦闘でカフカをすばやくテストし、それを主要な輸送モードとして使用し続けるかどうかを決定することができました。



ただし、このアプローチには重大な欠点があります。メッセージには入力と検証がありません。トピックからどのメッセージ形式を読み取ったかはわかりません。



これにより、データを提供するサービスとデータを消費するサービスの間でエラーや不整合が発生するリスクが高まります。



この問題を解決するために、ラッパー（Goのマイクロサービス）を作成しました。これは、KafkaをAPIの背後に隠します。これにより、次の2つの利点が追加されました。

• 送受信時のデータ検証。実際、これらは同じDTOであるため、予想されるデータの形式には常に自信があります。
• 私たちのサービスとこのトランスポートの迅速な統合。

したがって、Kafkaでの作業は、サービスにとって可能な限り抽象的なものになりました。これらは、このラッパーのトップレベルAPIでのみ機能します。

例に戻りましょう

同期インタラクションをイベントバスに転送するには、データフローを反転する必要があります。要求したものは、Kafka自体を経由する必要があります。この例では、宅配便の座標について説明しています。ここでは、特別なトピックを作成し、サービスによって宅配便業者から受け取ったときにそれらを作成しますlogistics-couriers。



サービスcourier-trackerは、必要な量と期間だけ座標を蓄積する必要があります。その結果、エンドポイントは可能な限りシンプルになります。サービスデータベースからデータを取得し、モバイルアプリケーションに提供します。それに対する負荷の増加は今や私たちにとって安全です。







その結果、特定の問題を解決することに加えて、クーリエの実際の座標を含むデータトピックを取得します。これは、どのサービスでも独自の目的に使用できます。

最終的に一貫性

この例では、クーリエの座標が同期オプションと比較して常に最新であるとは限らないことを除いて、すべてがクールに機能します。非同期相互作用に基づいて構築されたアーキテクチャでは、任意の時点でのデータの関連性について疑問が生じます。ただし、常に最新の状態に保つ必要のある重要なデータは多くないため、このスキームは理想的です。システムの可用性のレベルを上げるために、一部の情報の関連性を犠牲にします。ただし、最終的には、システムのすべての部分で、すべてのデータが関連性があり、一貫性がある（最終的には一貫性がある）ことを保証します。



このデータの非正規化は、高負荷のシステムとマイクロサービスアーキテクチャの場合に必要です。各サービス自体が、機能するために必要なデータのストレージを保証します。たとえば、私たちのドメインの主要なエンティティの1つは宅配便です。多くのサービスはそれを使用して動作しますが、それらはすべて異なるデータのセットを必要とします。誰かが個人データを必要とし、誰かが動きのタイプに関する情報のみを必要とします。このドメインのデータマスターはエンティティ全体をストリームに生成し、サービスは必要な部分を蓄積します。







したがって、サービスをデータマスターであるサービスとこのデータを使用するサービスに明確に分割します。実際、これは進化のアーキテクチャからのヘッドレスコマースです。すべての「ストアフロント」（Webサイト、モバイルアプリケーション）をこのデータの作成者から明確に分離しました。

非正規化

別の例：宅配便業者に的を絞った通知を行うメカニズムがあります。これらは、アプリケーションで宅配便業者に届くメッセージです。バックエンド側には、そのような通知を送信するための強力なAPIがあります。その中で、特定の基準に従って特定の宅配便業者から宅配便業者のグループまで、郵送フィルターを構成できます。



サービスはこれらの通知を担当しますlogistics-courier-notifications。彼が送信要求を受け取った後、彼のタスクは、ターゲットにされたそれらの宅配便業者へのメッセージを生成することです。これを行うには、彼はすべてのデリバリークラブの宅配便業者に関する必要な情報を知る必要があります。そして、この問題を解決するための2つのオプションがあります。

• サービス側にエンドポイントを作成します-クーリエデータウィザード（logistics-couriers）。送信されたフィールドによって必要なクーリエをフィルタリングして返すことができます。
• 必要なすべての情報をサービスに直接保存し、対応するトピックからそれを消費し、将来フィルタリングする必要があるデータを保存します。

メッセージを生成し、クーリエをフィルタリングするためのロジックの一部はロードされず、バックグラウンドで実行されるため、サービスのロードについては問題ありませんlogistics-couriers。しかし、最初のオプションを選択すると、一連の問題に直面します。

• サードパーティのサービスで高度に専門化されたエンドポイントをサポートする必要があります。これは、おそらく私たちだけが必要とします。
• 幅が広すぎるフィルターを選択すると、HTTP応答に単純に適合しないすべてのクーリエがサンプルに含まれるため、ページネーションを実装する必要があります（サービスをポーリングするときにそれを繰り返す必要があります）。

明らかに、サービス自体にデータを保存することをやめました。自律的かつ分離してすべての作業を実行し、どこにもアクセスせず、Kafkaトピックから必要なすべてのデータをそれ自体から蓄積するだけです。後で新しい宅配便の作成についてのメッセージを受け取るリスクがあり、それは一部の選択に含まれません。しかし、非同期アーキテクチャのこの欠点は避けられません。



その結果、サービスを設計するためのいくつかの重要な原則を策定しました。

• サービスには特定の責任が必要です。本格的な機能のためにサービスがまだ必要な場合、これは設計上の誤りです。それらを組み合わせるか、アーキテクチャを修正する必要があります。
• 同期呼び出しを批判的に調べます。一方向のサービスの場合、これは許容されますが、異なる方向のサービス間の通信の場合、これは許容されません。
• 何も共有しません。それらをバイパスするサービスのデータベースにはアクセスしません。APIを介したすべてのリクエスト。
• 仕様第一。まず、プロトコルについて説明し、承認します。

したがって、受け入れられている原則とアプローチに従ってシステムを繰り返し変換すると、次のアーキテクチャ







に到達しました。すでにかなりの数のデータストリームを持つKafkaの形式のデータバスがすでにありますが、方向間で同期要求があります。

アーキテクチャの開発計画

冒頭で申し上げましたように、デリバリークラブは急速に成長しており、膨大な数の新機能をリリースしています。そして、さらに実験を行い（Nikolay Arkhipovがこれについて詳細に話しました）、仮説をテストします。これらすべてにより、膨大な数のデータソースと、それらを使用するためのさらに多くのオプションが生まれます。そして、データフローの正しい管理。これは正しく構築するために非常に重要です。これが私たちの仕事です。



今後も、すべてのDelivery Clubサービスに対して開発されたアプローチを実装し続けます。つまり、データバスの形式でトランスポートを備えたプラットフォームの周りにサービスエコシステムを構築します。



主なタスクは、システム内のすべてのドメインに関する情報がデータバスに確実に提供されるようにすることです。新しいデータを使用する新しいサービスの場合、これは問題ではありません。サービスの準備段階で、ドメインデータをKafkaにストリーミングする必要があります。



しかし、新しいサービスに加えて、メインドメインである注文と宅配便に関するデータを使用した大規模なレガシーサービスがあります。このデータを「現状のまま」ストリーミングすることは問題があります。これは、数十のテーブルに分散して保存され、毎回すべての変更を生成する最終エンティティを構築するのに非常にコストがかかるためです。



そのため、古いサービスにはDebeziumを使用することにしました。、bin-logに基づいてテーブルから直接情報をストリーミングできます。その結果、テーブルの生データを使用して既成のトピックを取得できます。ただし、元の形式での使用には適していないため、カフカレベルのトランスを介して、消費者が理解できる形式に変換され、新しいトピックにプッシュされます。したがって、テーブルからの生データを含む一連のプライベートトピックがあり、これは便利な形式に変換され、消費者が使用できるようにパブリックトピックにブロードキャストされます。







Kafkaやさまざまな種類のトピックに書き込むためのエントリポイントがいくつかあるため、さらに、ストレージ側で役割ごとのアクセス権を実装し、Confluentを介してデータバス側でスキーマ検証を追加します。



データバスからさらに離れて、サービスは必要なトピックからのデータを消費します。そして、私たち自身がこのデータをシステムに使用します。たとえば、KafkaConnectを介してElasticSearchまたはDWHにストリーミングします。後者の場合、プロセスはより複雑になります。その中の情報をすべての人が利用できるようにするには、個人データをすべて削除する必要があります。



また、モノリスの問題を最終的に解決する必要があります。近い将来に耐える重要なプロセスがまだあります。最近では、注文作成の最初の段階であるバスケットの作成、受け取り、支払いを処理する別のサービスをすでに展開しています。次に、このデータをモノリスに送信してさらに処理します。さて、他のすべての操作はもはや同期を必要としません。

クライアントに対してこのリファクタリングを透過的に行う方法

もう1つの例、レストランのカタログについて説明します。明らかに、これは非常に忙しい場所であり、Goの別のサービスに移動することにしました。開発をスピードアップするために、テイクアウェイを2つの段階に分けました。

1. まず、サービス内で、モノリスのベースのレプリカに直接移動し、そこからデータを取得します。
2. 次に、Debeziumを介して必要なデータのストリーミングを開始し、サービス自体のデータベースに蓄積します。

サービスの準備が整うと、サービスを現在のワークフローに透過的に統合する方法が疑問視されます。トラフィック分割スキームを使用しました。クライアントからのすべてのトラフィックがサービスmobile-gatewayに送られ、モノリスと新しいサービスに分割されました。最初は、モノリスを介してすべてのトラフィックを処理し続けましたが、それらの一部を新しいサービスに複製し、それらの応答を比較して、メトリックの不一致に関するログを書き留めました。これにより、戦闘条件でのサービスのテストの透明性を確保しました。その後、新しいサービスがモノリスを完全に置き換えるまで、徐々に切り替えてトラフィックを増やすだけでした。



一般的に、私たちは野心的な計画やアイデアをたくさん持っています。私たちはさらなる戦略の開発を始めたばかりですが、その最終的な形は明確ではなく、すべてが期待どおりに機能するかどうかは不明です。実装して結論を​​出すとすぐに、結果を確実に共有します。



これらすべての概念の変更に加えて、私たちは積極的に機能を開発し、製品に提供し続けますが、これにはほとんどの時間がかかります。ここで、最初に説明した2番目の問題について説明します。開発者の数（180人）を考慮すると、新しいサービスのアーキテクチャと品質を検証するという問題が発生します。新しいものはシステムを劣化させてはならず、最初から正しく組み込まれている必要があります。しかし、これを産業規模で制御する方法は？

建築委員会

その必要性はすぐには生じませんでした。開発チームが小さかったとき、システムへの変更は簡単に制御できました。しかし、人が多ければ多いほど、それを行うのは難しくなります。



これにより、実際の問題（不適切な設計のためにサービスが負荷に耐えられなかった）と概念的な問題（「同期してここに移動しましょう。負荷が小さい」）の両方が発生します。



ほとんどの問題がチームレベルで解決されていることは明らかです。しかし、現在のシステムへのある種の複雑な統合について話している場合、チームは単に十分な専門知識を持っていない可能性があります。したがって、私はあらゆる方向からの人々のある種の協会を作りたかったのです。それに対して、建築についての質問を持ち、徹底的な答えを得ることができました。



そこで、チームリーダー、ディレクションリーダー、CTOを含むアーキテクチャ委員会を設立しました。私たちは2週間ごとに会合を開き、システムで計画されている主要な変更について話し合うか、特定の問題を解決します。



その結果、大きな変更を制御することで問題を解決しました。DeliveryClubのコードの品質に対する一般的なアプローチの問題が残っています。さまざまなチームのコードまたはフレームワークの特定の問題は、さまざまな方法で解決できます。私たちはSpotifyモデルでギルドに来ました：これらはいくつかの技術に無関心ではない人々の組合です。たとえば、ギルドGo、PHP、Frontendがあります。



彼らは統一されたプログラミングスタイル、設計とアーキテクチャへのアプローチを開発し、エンジニアリング文化の形成と維持を支援します最高レベルで。また、独自のバックログがあり、その中で内部ツール、たとえばマイクロサービス用のGoテンプレートを改善します。

製品コード

大きな変更が建築委員会を通過し、ギルドがコードの文化全般を監視しているという事実に加えて、Confluenceでチェックリストを作成するという、本番用のサービスを準備する重要な段階がまだあります。まず、チェックリストを作成するときに、開発者は自分の決定を再度評価します。第二に、これは運用上の要件です。これは、本番環境でどのような新しいサービスが表示されるかを理解する必要があるためです。



チェックリストは通常​​、次のことを示しています。

• サービスに責任があります（これは通常、サービスの技術リーダーです）。
• カスタマイズされたアラートを含むダッシュボードへのリンク。
• サービスの説明とSwaggerへのリンク。
• 相互作用するサービスの説明。
• サービスの推定負荷。
• health-check. URL, . Health-check - : 200, , - . , health check URL’ , , , PostgreSQL Redis.

サービスアラートは、アーキテクチャの承認の段階で設計されています。開発者は、サービスが有効であることを理解し、技術的な指標だけでなく製品の指標も考慮に入れることが重要です。ここでは、ビジネスコンバージョンを意味するのではなく、サービスが正常に機能していることを示す指標を意味します。



たとえばcourier-tracker、マップ上の宅配便業者を追跡する、上記ですでに説明したサービスを利用できます。その中の主な指標の1つは、座標が更新される宅配便業者の数です。突然、一部のルートが長期間更新されない場合、「問題が発生しました」というアラートが表示されます。どこかでデータを取得しなかったか、データベースに誤って入力したか、他のサービスが失敗した可能性があります。これは技術的な指標や製品の指標ではありませんが、サービスの実行可能性を示しています。



指標については、GraylogとPrometheusを使用し、ダッシュボードを作成し、Grafanaでアラートを設定します。



準備の量にもかかわらず、本番環境へのサービスの提供は非常に高速です。すべてのサービスは最初にDockerにパッケージ化され、Kubernetesの型付きチャートが作成された後、自動的にステージにロールアウトされ、その後、すべてがJenkinsのボタンによって決定されます。



prodへの新しいサービスの展開は、Jiraの管理者にタスクを割り当てることで構成されます。これにより、以前に準備したすべての情報が提供されます。

フードの下

現在、PHPとGoで記述された162のマイクロサービスがあります。それらは約50％から50％のサービス間で分散されました。最初に、Goでいくつかの高負荷サービスを書き直しました。その後、Goは本番環境での保守と監視が容易であり、エントリのしきい値が低いことが明らかになりました。そのため、最近はGoのみでサービスを作成しています。 Goの残りのPHPサービスを書き直す目的はありません。それは、その機能を非常にうまく処理します。



PHPサービスには、Symfonyがあり、その上に独自の小さなフレームワークを使用しています。これは、サービスに共通のアーキテクチャを課します。そのおかげで、サービスのソースコードを入力するためのしきい値が低くなります。どのサービスを開いても、そのサービスの内容と場所が常に明確になります。また、フレームワークは、サービス間の通信のトランスポートレイヤーもカプセル化します。開発者にとって、サードパーティサービスへの要求は、高レベルの抽象化を検討します。

$courierResponse = $this->courierProtocol->get($courierRequest);

ここで、要求のDTOを形成し（$courierRequest）、特定のエンドポイントのラッパーである特定のサービスのプロトコルオブジェクトのメソッドを呼び出します。内部では、オブジェクトは$courierRequestリクエストオブジェクトに変換され、DTOからのフィールドで埋められます。これはすべて柔軟性があります。フィールドは、ヘッダーとリクエストURL自体の両方に挿入できます。次に、リクエストはcURLを介して送信され、Responseオブジェクトを取得して、期待するオブジェクトに変換し直します$courierResponse。



これにより、開発者は、低レベルでの対話の詳細なしで、ビジネスロジックに集中できます。プロトコルのオブジェクト、サービスの要求と応答は、別のリポジトリ（このサービスのSDK）にあります。このおかげで、そのプロトコルを使用したいサービスは、SDKをインポートした後、型付きプロトコルパッケージ全体を受け取ります。



ただし、このプロセスには大きな欠点があります。すべてのDTOが手動で記述されるため、SDKを使用したリポジトリの保守が難しく、便利なコード生成が容易ではありません。試行はありましたが、最終的にはGoへの移行を考えると、それに時間を費やしませんでした。



その結果、サービスプロトコルの変更は、サービス自体、SDK、およびこのプロトコルを必要とするサービスなど、いくつかのプルリクエストに変わる可能性があります。後者では、変更が反映されるように、インポートされたSDKのバージョンを上げる必要があります。これにより、新しい開発者からよく質問が寄せられます。「パラメータを変更したばかりなのに、なぜ3つの異なるリポジトリに3つのリクエストを行う必要があるのですか？！」



Goでは、すべてがはるかに簡単です。優れたコードジェネレーターがあります（Sergey Popovがこれに関する詳細な記事を書きました））、そのおかげでプロトコル全体が入力され、現在、すべての仕様を別のリポジトリに保存するオプションについても議論されています。したがって、誰かが仕様を変更した場合、それに依存するすべてのサービスはすぐに更新されたバージョンの使用を開始します。

テクニカルレーダー

すでに述べたGoとPHPに加えて、私たちは他の膨大な数のテクノロジーを使用しています。それらは方向ごとに異なり、特定のタスクによって異なります。基本的に、バックエンドでは次のものを使用します。

• Python、データサイエンスチームが書いています。
• KotlinおよびSwift-モバイルアプリケーションの開発用。
• PostgreSQLデータベースとしてですが、一部の古いサービスはまだMySQLを実行しています。マイクロサービスでは、いくつかのアプローチを使用します。各サービスには独自のデータベースがあり、何も共有しません。サービスをバイパスするデータベースにはアクセスせず、APIを介してのみアクセスします。
• ClickHouse -分析に関連する高度に専門化されたサービス用。
• RedisおよびMemcachedメモリ内ストレージとして。

テクノロジーを選択するとき、私たちは特別な原則に導かれます。主な要件の1つは、使いやすさです。開発者にとって最もシンプルで理解しやすいテクノロジーを使用し、受け入れられたスタックに可能な限り準拠します。特定のテクノロジーのスタック全体を知りたい人のために、非常に詳細なテクニカルレーダーをまとめました。

短編小説

その結果、モノリシックアーキテクチャからマイクロサービスアーキテクチャに移行し、コアおよびデータマスターであるプラットフォームの周囲の方向（ドメイン領域）によって統合されたサービスのグループがすでに存在します。



私たちは、データストリームを再編成する方法と、新機能の開発速度に影響を与えずに再編成する方法についてのビジョンを持っています。将来的には、これが私たちを導いた場所について確実にお知らせします。



また、知識の積極的な移転と変更を加える正式なプロセスのおかげで、アーキテクチャの変革プロセスを遅らせることのない多数の機能を提供することができます。



読んでくれてありがとう！