架构师训练营第 2 期 第 10 周总结

1、我也遇到过不少这种情况：需求越提越多，即使砍掉部分实际不是需求的需求，项目内为此变更的代码也日益增多，甚至很多时候将错就错变成了成本最低的方案，项目失去原样。这就是课程说的，设计没法维持原来的逻辑一致性。等到积重难返，不得不重构，若仍然不改变指导思想，只是死循环。

2、领域驱动设计，是重视了上面的这种场景，提出的解决思路，要从源头把控，把项目能够约束在合理的框架内。从（业务需求）领域出发，划分为多个子类，且划分原则，以及未来目标都是子类领域概念要始终保持一致。关于这些个子域的边界，则用限界上下文控制。从编程的角度来讲，编写抽象方法，子类继承会引用去实现，是稳定的；而重新新增处理方法的，或者违背里式替换原则的，极具个性化，不稳定。

3、注意重点是从业务上提取而来的需求，而不是业务本身。

4、但要不要用微服务？

微服务不是万能的，我们想要将系统模块解耦，但没法先入为主，为微服务而微服务。

前提是必须能重构出独立业务模块，然后纳入技术因素考量，判断服务划分出模块的可行性。商讨过程中如果发现存在服务功能因需求多变，谨慎处置该部分。