战略设计包含三项：适应度函数，增量，架构耦合
适应度函数:
在战略实施的时候我们需要确定好测试策略，技术债管理，交互 。
测试策略在结构上可以包括：
（1）测试级别：常见的测试级别有单元测试，集成测试和系统测试。
从是否关心软件内部结构和具体实现的角度划分：白盒测 试，黑盒测试，灰盒测试
（2）角色与职责：需要在测试策略里面明确定义各个角色，以及该角色的职责。
（3）环境需求：这一点非常重要，它将描述测试时需要的系统环境，包括软硬件以及网络环境等等。
在澄清环境需求的时候，测试组织可以识别出资源方面的风险。
（4）风险分析：影响测试过程的风险都应该尽早被识别出来，而且必须有相应的解决办法以便消除或者减轻这些风险。
（5）测试进度：测试进度将会评估完成测试所需要的时间。
因为测试过程中充满了各种不确定性，所以一般计划者需要考虑增加一定的buffer
（6）回归测试方法：回归测试用来保证之前fix bug的代码不会影响软件的其他部分，
这样需要我们选择已经执行过的测试用例重新运行。
（7）测试范围：这个没啥好说的，就是你要测试的内容，可能是某些模块，可能是某些指标，比如功能，性能，易用性…
（8）测试优先级：测试范围内的东西不会都是一样重要的，加上测试资源各种有限，所以为测试排定优先级是十分的必要
技术债管理：
技术债用于描述理想中的解决方案和当前解决方案中间的差距所隐含的潜在成本(当然也需要注意其中的“利息”问题。)
技术债治里需要注意几个要点:
核心领域优于其他子域
识别领域、子域是DDD战略设计的重要步骤，在识别子域之后我们还需要进一步分析哪些是核心域（Core Domain），
哪些是支撑子域（Supporting SubDomain）和通用子域（Generic Subdomain）。
核心域在业务上至关重要，它提供了区别于行业竞争对手的差异化优势，承载了业务背后最核心的基础理念。
DDD概念的提出者 Eric Evans 是这样描述核心域的：
The Core Domain should deliver about 20% of the total value of the entire system,
be about 5% of the code base, and take about 80% of the effort.
可演进性优于可维护性
技术债导致的可演进性问题大多和架构相关，比如服务和服务之间的循环依赖、模块和模块之间的过度耦合、
缺少模块化和服务边界的“大泥球”组件等，
在添加新的功能时，这些架构的坏味道会给产品功能的迭代造成不少麻烦。
比如服务之间如果存在循环依赖的问题，当你对系统进行少量更改时，它可能会对其他模块产生连锁反应，
这些模块可能会产生意想不到的错误或者异常。
此外，如果两个模块过度耦合、相互依赖，则单个模块的重用也变得极其困难。
明确清晰的责任定义优于松散无序的任务分配
增量
顾名思义就是技术债和交互的BUFFER
架构耦合
(1)解耦模式: 我们通过依赖倒置，控制反转，依赖注入，面向接口等技术上的方式来降低耦合度
（2)安全策略:防范XSS攻击,注入攻击，CSRF攻击，Session劫持，Error Code，轮询，DDoS攻击等，
现阶段除了一些功能安全通过编码解决外其他主要依靠防火墙和云服务商来防范。
（3)技术债管理：接上文
（4)架构模式：模块化，插件化，分层架构，依赖管理，微服务化
转载请标明出处
