技术选择由** Feature Team ** 制作和假定。
特征小组必须采取负责任的行动来确定仅影响其的选择以及影响组织的选择。
必须由组织或对等收敛过程验证 超过特征小组范围的选项（例如，许可证，不经常使用的编程语言） 。
正确的工具 好用是节省资金的来源。
对每个人强加的工具都是的风险。滥用的好工具可能会造成非常严重的后果**。例如，很少使用的敏捷方法是危险的。
工具必须质疑。
** Excel 通常是理性的选择，但它不是一个可以做所有事情的工具**（CRM，ERP，Datamart，…）
Privilege ** Build **为核心业务。
考虑购买，其余情况。
一个工具带有一个功能区分功能的组织越多，它就越有可能被构建。核心业务必须允许特异性和快速且经常适应。有些软件包**有时会根据这种需要进行调整。
对于其余的：SaaS，开源，构建或所有者需要逐案研究**。
充分利用开源。
替代选择必须得到支持。
专有解决方案对于组织来说是风险，必要时必须能够恢复维护。
很少有专有工具没有开源替代品。
该组织从开源社区获益，并可以偿还其捐款**。
开发独立和弱耦合服务。
弱耦合必须是标准。
每个微服务都有一个明确定义的界面**。
这个接口决定微服务之间的链接。
域驱动设计允许（尤其是有界上下文）预测此问题。
每项服务都有自己的**数据存储系统。
A 数据存储仅用于单个微服务。
从一个微服务到另一个微服务的数据访问仅通过其接口完成。
这种设计意味着整个平台随时间的一致性。它必须在所有级别**被包括，包括用户体验。
每个微服务都必须有一个合理的功能边界，这个“适合头部”**。
微服务提供合理数量的功能。
毫不犹豫地在微服务开始增长时削减服务。
如果需要，一个合理大小的服务使有可能平静地考虑重写。
反应式宣言为反应式体系结构的设计开辟了道路。
响应式编程侧重于数据流和变化传播。它基于“** Observer ”模式，与传统的“ Iterator **”相反。
反应宣言设定了基本轴线：可用性和速度，韧性到故障，灵活性，弹性和信息定向。
异步过程有利于解耦和可扩展性，有利于性能。
应用程序之间的交换必须首先是异步。
异步交换自然允许弱耦合，隔离和流量控制（反压**）。
只有当动作需要时才应考虑同步通信**。
信息系统必须面向事件。
** 事件驱动功能过程 自然 异步实现。
事件定向允许有助于实施诸如** C ** ommand ** Q ** uery ** R 责任 ** S ** egregation（** CQRS ** ）和事件采购。
特权简单，强大且强大的消息代理到“智能管道”。
** ESB 显示限制：可扩展维护是严重，无论从技术还是组织**观点。
** ** 卡夫卡等经纪讯息提供简单，耐用和韧性解决方案。
智能端点和简单管道是一种大规模工作的架构：它是** Internet **。
系统的完全同步应该在设计时尽快考虑。
如果事件流程确保两个系统之间的同步，则这些系统的总重新同步必须在设计时进行计划。
自动** ** 同步审计（例如：按样本）允许测量和检测任何可能的同步错误。
服务的配置是集中，发现由目录保证。
微服务的配置对于所有环境都是集中。
中央目录确保微服务的动态发现**。
** 全局可扩展性取决于这个目录**。
功能团队提供沙箱环境。
Feature Team维护一个** sandbox 环境（当前版本和即将发布的版本）以允许其他团队扩展**。
在一些非名义的情况下，功能可能在开发环境中被禁用。
您的系统将崩溃！
设计它，使其宽容。
你的系统会崩溃，这是不可避免的。它必须为此设计（** Design For Failure **）。
在所有级别预测冗余：硬件（网络，磁盘等），应用程序（多个应用程序实例），地理区域，提供程序（例如：AWS + OVH）。
提供工具包，不要强加严格的框架。
注意技术组件房屋和横向！它们是限制性的，昂贵且难以维护。
加速器，工具箱，技术堆栈可以汇集，免费功能团队，避免教条式的方法。
公共，私人或混合型，云（** IaaS 或 PaaS **）是生产标准。
** PaaS 服务优先，简单**，并且快速扩展。
** IaaS 服务允许您解决需要更大灵活性**的情况，但需要更多的操作工作。
私有云不是传统的虚拟化环境，它依赖商品硬件。
功能团队不管理基础设施，它由提供和维护。
基础设施问题不在功能团队内。基础架构必须由交叉功能服务提供和维护**。
容器提供了异构工具所需的灵活性。
容器提供特性团队所需的灵活性，以便在均匀上下文中启用异构工具**。
使用容器可以解决技术环境的问题。
这些容器（例如：** Docker ）使得可以释放环境的差异。
部署过程对环境必须是不可知的。
一些组件如数据库不应该部署在容器中。他们的部署仍然是自动的。
所有措施必须是集中和可访问。
指标对于具有不同粒度级别的所有人都是可访问：相关团队特征的详细视图，该组织其他成员的聚合。
访问指标并不意味着访问单元数据，必须对其进行控制以保持机密性。
所有环境都受到影响。
软件质量是关键因素。
代码评论是系统。作为持续改进的一部分，它们由特征小组的成员或组织的其他成员进行。
那不是你被审计的，而是你的代码：“你不是你的代码！”。
质量可以部分自动化，但没有什么比“新眼睛”。
自动化测试是持续部署的不可协商的先决条件。
自动测试确保产品的质量随着时间的推移**。
它是持续部署的先决条件，它允许** 更改和频繁部署。
生产推出成为轶事事件！
所有级别的测试：单元，集成，功能，弹性，性能。
整合和功能测试是最重要的，它们保证** 有效操作**。
单元测试适用于开发。
性能测试随着时间的推移衡量性能。
韧性测试有助于预测失败。
封面是测试质量的主要客观指标。
测试的代码覆盖率是代码质量的良好度量。
这是一个必要条件但是不够，不良测试策略的覆盖率可能很高，而不保证代码的高质量。
安全性是一个过程，不应该对问题进行处理。
** 安全专家可** 如果需要直接集成到功能团队中。
安全专家可在组织中获得审计，认识和转发。