面向复杂度的设计
DDD 是可扩展架构的设计技巧，不是架构方法论。不关注高性能、高可靠。
架构本质：为了降低软件系统复杂度
怎么做架构设计 ？思路是分析系统需求找到系统复杂的地方，然后设计方案。
复杂度相关有哪些？高性能、高可用，可扩展、安全、成本。。。
降低软件复杂度方式？分库分表、缓存、集群、分片、微服务、DDD。。。
通常流程
如何做好架构设计？
架构设计三原则
合适原则：
合适由于业内领先 。
资源：将军不打无准备之仗
时间：罗马不是一天建成的
业务：业务发展带来技术发展
简单原则：
简单优于复杂，相关：奥卡姆剃刀：若无必要，勿增实体
可靠性 ：越复杂越不可靠
可扩展：越复杂越难以扩展
故障处理效率：越复杂越难处理。
演化原则：
演化由于一步到位，演进目的：传承基因，适应变化。
创造：满足 当下业务需求
迭代优化：修改去留
重构：量变引起质变
架构设计原则 应用：
1设计出来的架构要满足当时的业务需要，符合团队和技术的能力水平（合适原则）
2先按照简单的方式来设计架构，然后不断地在实际应用过程中迭代优化（简单原则）
3 当业务发生变化时，架构要扩展、重构，甚至重写（演化原则）
常见判断维度
业务：
1.业务当前的量级 2.业务发展速度 3.业务的发展形态
团队：
1.团队规模 2.团队能力水平 3.投入的资源
技术：
1.已有技术体系2.当前技术能力3.技术成熟度
小结：
李老师还把经历的一些失败的架构案例，做了分析。不务实，各种 高大上目标，难以落地，或者坑太多填不过来。实际上复杂业务系统的重构困难重重，不是每次都能成功。牵扯的相关方多，沟通困难，要把相关的需求方，产品，研发等反复沟通。总有些历史逻辑无人知晓，评审发现不了，开发才发现。
结合郭东白老师的课，有些系统边界不清晰，比如有的订单冗余了非订单关注的太多属性，其他系统全靠从订单获取，那么你在维护订单的数据一致性成本就很高，看着没啥用，那你一改别的系统就出问题。还要现实考虑这种重构与业务需求优先级，平衡这个关系。所以老师这些列举的考量的点，真正落地还得面对现实。
