技術的な選択肢は、フィーチャーチームによって** ** ** ** ** **は想定されています。
フィーチャーチームは、責任ある行動を行い、排他的に影響を与える選択肢と組織に影響を与える選択肢を特定する必要があります。
フィーチャーチームの範囲を超える選択肢（ライセンス、まれなプログラミング言語など）は、組織またはピアコンバージェンスプロセスによって検証されなければなりません** 。
正しい使い方のための正しいツール**は節約の源です。
すべての人に課された悪いツールはリスクです。良いツールの誤用は非常に有害な結果**を持つことができます。たとえば、あまり使用されていないアジャイルメソッドは危険です。
ツールは質問する必要があります。
** Excel はしばしば合理的な選択肢ですが、すべてを行うための **（CRM、ERP、Datamart、…）
特権コアビジネスのためのビルド
その他の場合は、購入を考慮してください。
ツールが組織の機能を差別化する機能を備えているほど、構築される方が多くなります。コアビジネスは特異性を可能にする必要があり、は迅速かつ頻繁に適応しなければなりません。いくつかのソフトウェアパッケージは、このニーズに合わせて適応されることがあります。
** その他の場合：SaaS、オープンソース、ビルド、オーナーはケースバイケースで学びます。
オープンソースを最大限に活用。
代わりの選択肢をサポートする必要があります。
プロプライエタリなソリューションは、必要に応じてメンテナンスを再開できる必要がある組織のリスクです。
オープンソースの代替手段を持たないプロプライエタリなツールはほとんどありません。
組織はオープンソースコミュニティーのメリットを提供し、は貢献することができます。
スタンドアロンおよび弱く結合したサービスを開発する。
弱いカップリングは標準でなければなりません。
各マイクロサービスは明確に定義されたインターフェースを持っています。
このインターフェースはマイクロサービス間のリンクを決定します。
ドメイン駆動設計では、特に有界コンテキストでこの問題を予期することができます。
各サービスには独自の**データストレージシステムがあります。
データストアは、単一のマイクロサービスとのみ結合されることを意図しています。
あるマイクロサービスから別のマイクロサービスへのデータへのアクセスは、そのインターフェースを介して排他的に行われます。
この設計はプラットフォーム全体の時間の経過と共に一貫性を意味します。 UXを含むすべてのレベルで認識されなければなりません。
各マイクロサービスは、合理的な機能的境界を持っていなければなりません** 「頭に合っている」。
マイクロサービスは合理的な数の機能を提供します。
成長が始まると、マイクロサービスを切断するのをためらってください。
リーズナブルなサイズのサービスは、必要に応じて書き換え**を穏やかに検討することを可能にします。
** Reactive Manifesto **は、反応性のあるアーキテクチャの設計に向かう道を開きます。
レスポンシブなプログラミングは、データの流れと変化の伝播に焦点を当てています。これは、より伝統的なアプローチ "反復子"に反するパターン "** Observer **"に基づいています。
リアクティブマニフェストは基本的な軸を設定します：可用性とスピード、反発力、柔軟性、弾力性、メッセージオリエンテーション**。
非同期プロセスはデカップリングを、スケーラビリティはパフォーマンスを優先します。
アプリケーション間の交換は非同期でなければなりません。
非同期交換は自然に弱いカップリング、分離、フロー制御（背圧）を可能にします。
同期通信は、アクションがそれを必要とするときのみ**考慮されるべきです。
情報システムは、イベントを指向していなければなりません。
** イベント駆動型機能プロセスは自然に 非同期に実装されています。
イベントオリエンテーションは、** C と Q ** uery ** R の可能性 S ** egregation（** CQRS ** ）と** Event Sourcing **です。
特権シンプルで堅牢で強力なメッセージブローカーを "スマートパイプ"に特権を与えます。
** ESB は限界を示しました：スケーラブルなメンテナンスは技術と組織の観点の両方から重要**です。
** カフカのようなブローカーメッセージは、シンプルな、耐久、弾力のあるソリューションを提供します。
スマートエンドポイントとシンプルパイプは規模で動作するアーキテクチャです。インターネットです。
システムの完全な同期は、** 設計されるとすぐに考えられるべきです。
イベントフローによって2つのシステム間の同期が保証されている場合、これらのシステムの合計再同期は設計時に計画する必要があります。
自動** ** 同期監査（例：サンプル別）は、測定および可能な同期エラーの検出を可能にします。
サービスの構成は集中、発見はディレクトリによって保証されています。
マイクロサービスの構成はすべての環境のための集中です。
中央ディレクトリはマイクロサービスの動的検索を保証します。
** グローバルスケーラビリティはこのディレクトリ**に依存します。
フィーチャーチームはサンドボックス環境を提供します。
フィーチャーチームはサンドボックス環境（現在のバージョンと今後のリリース）を維持して、他のチームを拡大することができます。
いくつかの非名義のケースでは、機能は開発環境で無効になることがあります。
あなたのシステムはクラッシュするでしょう！
それが耐性を持つように設計する。
あなたのシステムは失敗します、それは避けられません。このために設計されていなければなりません（** Design For Failure **）。
ハードウェア（ネットワーク、ディスクなど）、アプリケーション（複数のアプリケーションのインスタンス）、地理的なゾーンプロバイダ**（例：AWS + OVH）。
** toolkits **を提供し、厳格な枠組みを課してはいけません。
テクニカルコンポーネントの住宅および横断への注意！それらは制限的で、費用がかかり、維持するのが難しい。
アクセラレータ、ツールキット、テクニカルスタック プール、無料フィーチャーチーム、独断的なアプローチを避ける。
パブリック、プライベートまたはハイブリッドのクラウド（** IaaS または PaaS **）は、制作の標準です。
** PaaS サービスは優先、簡単**、および規模をすばやく調整できます。
** IaaS サービスでは、柔軟性**を高める必要があるケースに対処できますが、より多くの運用作業が必要になります。
プライベートクラウドは従来の仮想化環境ではなく、コモディティハードウェアに依存しています。
フィーチャーチームはインフラストラクチャを管理していませんが、組織によって提供され管理されています。
インフラストラクチャの問題は** Feature Teams にありません。インフラストラクチャは機能×サービスによって提供され維持されなければなりません。
コンテナは異機種ツーリングに必要な柔軟性を提供します。
コンテナは異質なツールを同種のコンテキストで可能にするためにフィーチャーチームが必要とする柔軟性を提供します。
容器の使用は、技術環境の問題を克服することを可能にする。
コンテナ（例：** Docker ）は、環境の違いを **解放することを可能にします。
配備プロセスは環境に対して不可知論的でなければなりません。
データベースなどの一部のコンポーネントはコンテナに配置しないでください。彼らの展開はまだ自動化されています。
対策はすべてに中央およびアクセス**する必要があります。
指標は、異なるレベルの細かさを持つすべての人にアクセス可能です。関連するチームフィーチャーの詳細ビュー、組織の他のメンバーの集計。
指標へのアクセスはユニットデータへのアクセスを意味するものではなく、機密性を維持するように制御されなければなりません。
すべての環境が影響を受けます。
ソフトウェア品質は重要な要素です。
コードレビューは体系的です。 継続的改善の一環として、フィーチャーチームのメンバーまたは組織の他のメンバーが実施します。
あなたが監査されているのではなく、あなたのコード： "あなたはあなたのコードではありません！"
光度測定は部分的に自動化できますが、** "新しい目" に勝るものはありません。
自動テストは継続的な導入のための交渉可能な前提条件です。
自動テスト 時間の経過とともに製品の品質**を保証します。
継続的な導入には前提条件があります。** 変更および頻繁な展開が可能です。
プロダクションの公開は逸話イベントになります！
すべてのレベルでのテスト：ユニット、統合、機能性、反発力、パフォーマンス
統合および機能テストは最も重要です** 保証 ** 効果的な運用**
ユニットテストは開発に適しています。
パフォーマンスは時間の経過とともにパフォーマンスを測定します**。
弾力性テストは失敗を予測するのに役立ちます。
カバーはテスト品質の主な客観的指標です。
テストによるコードカバレッジは、コード品質の良いメトリックです。
これは、必要な条件ですしかし、十分ではありません、コードの良質を保証することなく、悪いテスト戦略の適用範囲が高くなります。
セキュリティはプロセスです。問題に応じて対処すべきではありません。
セキュリティ専門家はフィーチャーチームに直接統合することができます** 必要に応じて。
セキュリティ専門家は、監査、認識、フォワードのために組織内で利用可能です。