架构训练营笔记系列:面向复杂度的设计

面向复杂度的设计

  DDD 是可扩展架构的设计技巧，不是架构方法论。不关注高性能、高可靠。

架构本质：为了降低软件系统复杂度

怎么做架构设计 ？思路是分析系统需求找到系统复杂的地方，然后设计方案。

复杂度相关有哪些？高性能、高可用，可扩展、安全、成本。。。

降低软件复杂度方式？分库分表、缓存、集群、分片、微服务、DDD。。。

通常流程 

如何做好架构设计？

架构设计三原则

合适原则： 

   合适由于业内领先 。

    资源：将军不打无准备之仗

   时间：罗马不是一天建成的

   业务：业务发展带来技术发展

简单原则：

简单优于复杂，相关：奥卡姆剃刀：若无必要，勿增实体

  可靠性 ：越复杂越不可靠

  可扩展：越复杂越难以扩展

  故障处理效率：越复杂越难处理。

演化原则：

 演化由于一步到位，演进目的：传承基因，适应变化。

创造：满足 当下业务需求

迭代优化：修改去留

重构：量变引起质变

架构设计原则 应用：

  1设计出来的架构要满足当时的业务需要，符合团队和技术的能力水平（合适原则）

  2先按照简单的方式来设计架构，然后不断地在实际应用过程中迭代优化（简单原则）

  3 当业务发生变化时，架构要扩展、重构，甚至重写（演化原则）

常见判断维度

   业务：

1.业务当前的量级 2.业务发展速度 3.业务的发展形态

 团队：

  1.团队规模 2.团队能力水平  3.投入的资源

技术：

  1.已有技术体系2.当前技术能力3.技术成熟度

    小结：

    李老师还把经历的一些失败的架构案例，做了分析。不务实，各种 高大上目标，难以落地，或者坑太多填不过来。实际上复杂业务系统的重构困难重重，不是每次都能成功。牵扯的相关方多，沟通困难，要把相关的需求方，产品，研发等反复沟通。总有些历史逻辑无人知晓，评审发现不了，开发才发现。

    结合郭东白老师的课，有些系统边界不清晰，比如有的订单冗余了非订单关注的太多属性，其他系统全靠从订单获取，那么你在维护订单的数据一致性成本就很高，看着没啥用，那你一改别的系统就出问题。还要现实考虑这种重构与业务需求优先级，平衡这个关系。所以老师这些列举的考量的点，真正落地还得面对现实。