关于架构的一些理念

1.架构是进化而来的

        罗马不是一天建成的，大公司的复杂架构也不是一蹴而就的，而是从简单到复杂演变、进化而来的。以淘宝为例，它的第一个版本是几名开发人员用了一个月的时间给予一个PHP版拍卖网改造而来的，上线时淘宝只有一台web服务器和一台数据库服务器。在淘宝近20年的发展中，随着网络的访问量越来越大，功能越来越多，淘宝网才逐渐演变成现在这样复杂的架构。现在很多网站开发第一版的时候就以“上亿访问，百万并发量”为架构设计目标，导致项目迟迟无法交付，研发成本高昂，好不容易开发完成了，但是由于项目交付延迟，公司已经错过了绝佳的市场机会，最后导致项目失败。

        按照“精益创业”的理念，我们应该用最低的成本，最短的时间开发一个“量小的可行性产品”，然后把产品投入市场，根据市场的反馈再进行产品的升级。经过IT行业的发展，我们现在已经可以用非常低的成本在很短的时间内构建一个可承担较大访问量的高可用系统。我们只要给予成熟的技术开发，并对项目未来将断一断时间内的发展进行预测，在项目架构上做必要的准备就可以了，没必要“想的太长远”。架构在满足必要的可扩展性、隔离性的基础上，要尽可能简单。

        一个优秀的架构不应该是初期版本简单，升级过程经常需要推到重来的，而是要从简单开始，并且可以顺滑地持续升级。也就是架构最开始的版本很简单，但是为后续的进化、升级做好了准备，以便后续可以完美的升级架构。这样可以持续升级的架构叫“演进式架构”。设计一个优秀的演进式架构比设计一个大而全的架构对架构设计人员的要求更高。

        .Net是一个可以很好的支撑演进式架构的技术平台。在前期网站访问量低。没有专业运维人员的情况下，我们可以把用.net开发的程序部署到单机Windows服务器上。随着网站规模的扩大，我们可以在不修改代码的情况下把程序迁移到Linux+docker的环境下。在网站访问量低的时候，我们可以用内存作为缓存。随着网站访问量的增大，我们可以切换为使用redis作为缓存。.net的依赖注入让我们可以替换服务的实现类，而不需要修改服务消费者的代码。

        一个好的软件架构应该是可以防止软件退化的。软件退化指的是软件升级的时候，随着功能的增加和系统复杂度的提升，代码的质量越来越差，系统的稳定性和可维护性等指标越来越差。一个最大的软件的明显特征就是软件的第一个版本是代码质量最高的版本。之后的版本中，代码质量越来越差。软件的需求是不断变更的，软件的升级也是必然的，因此我们应该再进行架构设计的时候，避免后续软件需求变更，导致软件退化，并且在软件的升级过程中，我们要适时的进行架构的升级，以保持高质量的软件设计。如果我们每次软件升级的时候，没有及时的调整程序结构，而是在原有的程序结构上不断的加入代码，最终的软件就会退化。

---

2.DDD的基本概念

        随着IT行业的发展，传统的单体结构项目已经无法满足如今的软件项目的要求，越来越多的项目采用微服务架构进行开发，DDD是一个很好的应用于微服务架构的方法论。

传统的软件项目大部分都是单体结构，也就是项目中的所有代码都放到同一个应用程序中。一般他们也都运行在同一个进程中。单体结构的项目有结构简单。部署简单等优点。但是有如下个缺点：

• 代码之间耦合严重。代码的可维护性低。
• 项目只能采用单一的语言和技术站，甚至采用的开发包的版本都必须统一。
• 一个模块的崩溃就会导致整个项目的崩溃。
• 我们只能进行服务器扩容，无法对其中的一个模块进行单独的服务器扩容。
• 当需求但需要更新某一个功能时，我们需要把整个系统重新部署一遍。这会导致新功能的上线流程变长。

微服务架构把项目拆分为多个应用程序，每个应用程序单独构建和部署，微服务架构有如下的优点：

• 每个微服务只负责一个特定的业务，业务逻辑简单，代码简单，对于其他微服务的依赖非常低。因此易于开发和维护。
• 不同的微服务可以用不同的语言和技术站开发。
• 一个微服务的运行不会影响其他服务。
• 可以对一个特定的微服务进行单独扩容。
• 当需要更新某一个功能的时候，我们只需要重新部署这个功能所在的微服务即可。不需要重新部署整个系统。

当然，万事万物不会只有优点，没有缺点。微服务架构的缺点如下：

• 在单体结构中，运维人员只需保证一个应用的正常运行即可。而在微服务架构中，运维人员需要保证多个应用的正常运行这给运维工作带来了更大的挑战。
• 在单体结构中，各个模块之间是进程内调用据交互的效率高。而微服务架构中各微服务之间要通过网络进行通信。数据交互的效率低。
• 在单体结构中，各模块之间的调用都是在进程内进行的，实现容错，事务一致性等比较容易。而在微服务架构中，做服务之间的通信，通过网络通。实现容错，事物一致性等非常困难。

我们讲过。架构应该是进化而来的。同样，微服务架构也应该是进化而来的。因此在进行系统架构设计的时候，我们应该认真思考，这个项目真的需要微服务吗？如果经过思考后我们仍然决定要采用微服务架构，那我也要在思考能不能减少微服务的数量。第一个版本的项目可以只有几个微服务，随着系统的发展，当我们发现一个微服务中某个功能已经发展到可以独立的程度时，我们再把这个功能拆分为一个微服务。总之，是否采用微服务及如何采用微服务，应该是仔细思考后的结果。我们不能盲目跟风。马丁-富勒（Martin Fowler）曾经提过：“分布是第一定律”，那就是“避免使用分布式”。因此我认为微服务第一定律，那就是“避免使用微服务，除非有充足的理由”。

3.DDD为什么难学

        DDD并不是一个技术，而是一种架构设计指导原则。DDD不是一种强制性的规范，各个项目可以根据自己的情况进行个性化的设计。DDD就像烹饪中餐时“盐少许、油少许”一样让人难以琢磨。而DDD中的概念非常多，表述非常晦涩。因此很多人都对DDD望而生畏。不同项目的行业情况、公司情况、团队情况、业务情况等不同，因此DDD不能给我们一个拿来就能照着用的操作手册。每个人每个团队对DDD的理解不同，如果说“一千个人心中就有一千个哈姆雷特”。那么也可以说“1000个人心中就有2000个DDD”，因为同一个人对滴也可能在不同时期有不同的理解。

        很多人把DDD当成一个技术，这是非常大的一个误区。DDD是一种设计思想。他分为战略设计和战术设计两个层次：DDD的战略设计可以帮助公司的领导人进行团队的划分，人员的组织，产品线的规划，也可以帮助产品经理对产品功能进行规划，还可以帮助架构师进行项目架构的规划，术站的选择等；DDD战术设计则是对公司全员进行DDD具体实施过程的指导

        很多开发人员学习DDD时候感觉无从下手。主要的原因就是他们把DDD当成一个整体去学习，从而找不到学习的落脚点。无论是公司管理人员、业务人员、架构师还是开发人员，在学习DDD的时候，应该先从自己能够把握的方面去学习DDD。随着对DDD应用的深入，在逐渐了解DDD的全貌。在DDD概念落地的时候，不同的技术站选择也会导致这些概念的实现方式不同。