前言
本文主要表达作为一名程序设计人员，甚至架构师在做设计的时候，经常要遵守的原则；但原则并不使用所有人，不同的设计思想对于不同的人有不同的认可程度，本文大部分偏向于协同而非编排的编程模式。
正文
1、减少副作用
尽量不要在方法中去修改入参的值，对对象的内部修改，最后在一个方法中可见，如果迫不得已可以利用DDD中的三种避免副作用的实践：
- 断言副作用；
- 把代码分为命令和查询，查询用函数式编程；
- 释意命名选择器
2、查询与命令分离
比较出名的有CQRS架构，分离后模型的演进会更加内聚；
3、分离复杂计算到Value Object中
减少副作用，使得状态变更更加简单，而复杂计算可以随便嵌套使用。
4、事务的主线与支线分离
程序的运行一般是一条线下来的，这条线最好是用作写业务主线的逻辑，而支线的逻辑应该使用一定的设计模式分离，例如：AOP，或者：配合观察者模式
5、领域隔离
该观点来自DDD，领域隔离，要求领域干净，无其他领域逻辑，这些要求落实到实际，就是：
- 不能依赖其他领域的实体，或者包
- 领域之间的交互要用适配器，定义好接口，因为接口是无法避免的依赖，所以接口最好用https等实现，避免语言依赖
- 数据库隔离，不能操作其他领域实体的数据库
- 一个领域逻辑要闭环
- 领域逻辑要和平台逻辑隔离，你可能知道DDD中服务是分领域服务和基础设施服务的，其实就是体现这种隔离的
- 事务与事务隔离，一般领域隔离后，事务的隔离会定义在领域之间，一个领域一个事务，而且多支持事务失败重试，方便做幂等
6、构建与运行分离
程序如果按照事件驱动，或者按照领域隔离，控制反转，那么一般你会发现，你会用到很多注册的动作；所以应该是有一段代码是用来执行程序之间的组装的，这段代码不涉及运行时，而是体现架构，就好比钢铁侠在战斗的时候，要先组装铠甲，然后再战斗，把这些组合控制和其他代码分开，用一个包表示，就是构建与运行分离的思想；
7、服务与框架分辨
很多时候，你会打算做一段抽象，那么你一定要先给你的抽象定义性质，它到底是服务，还是二方包，是平台，还是容器，是有状态的，还是无状态的；所以思考好之后，或许会给你很大的灵感，到底是要怎么设计你的抽象；把服务与框架分离，有利于服用和代码管理
8、平台与业务隔离
平台，顾名思义具有普适性，而业务则是变化多端的；
很多时候我们一个应用都是纯业务代码，当这样的代码过大过复杂的时候，通常需要治理，治理的方式有很多，例如微服务，但如果你的业务逻辑能后向上抽象，使得其可以分离出一个平台出来，那么最好这样来做，因为这意味着，你把业务的治理推向了自动化的路线，平台就是负责完成自动化的职责，通过平台会自动化你的业务的一整个生命周期；把好处总结如下：
- 升职加薪，你的老板leader最喜欢就是这类技术沉淀了
- 轻松进行业务与业务之间的隔离，你的平台会运行很多业务，把他们用包隔离开来，无疑是治理代码的最佳实践；
- 管理业务生命周期，很多业务都会有生命周期，那些混饭吃的产品基本会憋个见光死的业务给你，特别你是中台的时候，当你的业务无流量之后，可随时删除垃圾业务，避免形成垃圾堆
- 平台升级，造化业务，当然平台升级风险也是很大，但必须利大于弊，当你把底层引擎升级后，所有上层业务都会受益
常见的自动化平台入流程引擎，流程引擎不仅能让你知道你的每一个业务即时运行情况，历史流量，报错节点反应性能瓶颈等，所以请尽量隔离一个平台出来吧；
9、业务数据和平台数据分离
数据一般可以归类为两种，一个是属于业务数据，一个是属于平台数据，为什么平台会有数据呢？因为平台在执行业务的时候，平台的执行上下文是具有状态的，有状态必然有数据作为状态表达载体；分离的理由
- 不同领域，难免会有key冲突
- 方便维护，一般平台数据比较固定及格式化
10、业务代码与技术代码隔离
DDD中的核心思想之一，业务代码不变，需要技术更新迭代的时候，可以很好的支持，另外一个特定的技术代码在多个地方用到可以抽离出来，甚至可以做成技术中台。
