如何保持低成本维护与高质量的设计

先推荐一本书《领域驱动设计：软件核心复杂性应对之道》。

在过去的开发初期软件系统并没有那么复杂，即使软件维护了几年，软件退化，软件变得越来越不好维护，推到重新开发就好。随着软件行业的快速发展，软件规模越来越大，生命周期也越来越长，推到重新开发的风险越来越大，这里时候软件团队急需一个低成本的状态下去持续维护一个系统很多年。

这个时候微服务架构成为规模化的软件指导，不过微服务对设计提出了很高的要求，强调小而专、高内聚，否则就不能发挥出微服务的优势，甚至有可能变为适得其反的效果。

理解软件退化的根源

软件设计质量最高的时候是第一次设计的那个版本，当第一个版本设计上线以后就出现各种需求变更，这常常又会打乱原有的设计。因此，需求变更一次，软件就修改一次，软件质量就会下降一次，无论软件第一次设计质量有多高，软件经历不了几次变更就进入一种低质量、难于维护的状态，而软件团队就需要在这样状态下，以高成本的方式不断的维护下去，维护很多年。这时候维护原有的业务都很困难，又如何期望未来全新的业务呢？

软件的本质就是对真实世界的模拟，每个软件都能在真实世界中找到他的影子，因此，软件中的业务逻辑正确与否的唯一标准就是是否与真实世界一致，如果不一致用户就会提 bug 或新需求。

软件要做成什么样，既不由我们来决定，也不由用户来决定，而是由客观世界决定。用户为什么总是提需求，是因为他们也不确定客观世界的规则，只有遇到问题了，他们才能想得起来。

在我们不断的更改需求与修复 bug 的过程中，我们的软件的业务会越来越接近真实世界，使得我们的软件越来越专业，同时业务逻辑就会变得越来越复杂，软件规模也越来越庞大。

究其原因：软件的不断退化，并不是软件的变更，而是软件由简单变复杂的过程中不断的软件方法进行添加代码，不进行解耦操作，导致软件难以维护。

软件变更应当如何设计

要保持软件设计质量不退化，必须在每次需求变更的时候，对原有程序结构适当地进行调整

举例子：

在价格计算中，添加限时折扣、限量折扣、某类商品折扣与不折扣，添加了大量的折扣 else if 的判断，这样写代码违反了开放与封闭原则。

开放原则：对功能扩展是开放，即当系统需求发生变更时，可以对软件功能进行扩展，使其满足用户新的需求。

封闭原则：对软件代码的修改是封闭的，即当修改软件的同时，不要影响到系统原有的功能，所以应当在不修改原有代码的基础上实现新的功能。

如何使用开放与封闭原则

在不添加新功能的前提下，重构代码，调整原有程序结构，以适应新功能，实现新的功能

通过策略模式添加接口实现，既符合需求的添加开放原则，又能解决了修改封闭原则。

每一种“灵活设计”只能应对一种需求变更，只有在遇到问题的时候才进行设计，而不是在软件起初设计的时候进行大量的“灵活设计”，而成导致软件设计过度复杂且不能解决未来变更，而这些灵活的设计被称为“过度设计”。

如何保持软件的质量—领域驱动（DDD）

进过一两次软件的变更，通过开闭原则还能简单的调整还能搞明白，但是经过大量的变更与修改，往往我们会陷入迷茫，设计开始迷失方向。

通过领域驱动设计能够提供给我们设计的方向，将变更还原到真实世界中，根据真实世界进行变更，真实世界是什么样子，那么软件世界就怎么设计。

真实世界	软件世界
事物	对象
行为	方法
关系	关联

在每次变更的时候，先回到领域模型，基于业务进行领域模型的变更。