文章目录 一、传统架构的缺点二、DDD领域驱动1、DDD 包括战略设计和战术设计两部分。2、DDD的优势3、DDD设计原则4、微服务拆分需要考虑哪些因素？4.1、基于领域模型4.2、基于业务需求变化频率4.3、基于应用性能4.4、基于组织架构和团队规模4.5、基于安全边界4.6、基于技术异构 5、其他效率问题对设计和开发人员的要求相对较高
软件架构模式发展到现在可以主要经历了三个阶段：UI+DataBase的两层架构、UI+Service+DataBase的多层SOA架构、分布式微服务架构。
一、传统架构的缺点在前两种架构中，系统分析、设计和开发往往是独立、分阶段割裂进行的。
1、两层架构是面向数据库的架构，根本没有灵活性。
2、微服务盛行的今天，多层SOA架构已经完全不能满足微服务架构应用的需求，它存在这么一些问题
臃肿的servcie三层分层后文件的随意组装方式技术导向分层，导致业务分离，不能快速定位。比如，在系统建设过程中，我们经常会看到这样的情形：A 负责提出需求，B 负责需求分析，C 负责系统设计，D 负责代码实现，这样的流程很长，经手的人也很多，很容易导致信息丢失。最后，就很容易导致需求、设计与代码实现的不一致，往往到了软件上线后，我们才发现很多功能并不是自己想要的，或者做出来的功能跟自己提出的需求偏差太大。
在这两种模式下，软件无法快速响应需求和业务的迅速变化，最终错失发展良机。此时，分布式微服务的出现就有点恰逢其时的意思了。
二、DDD领域驱动虽说分布式微服务有这么好的优点，但也不是适合所有的系统，而且也会有许多问题。
微服务的粒度应该多大呀？微服务到底应该如何拆分和设计呢？微服务的边界应该在哪里？这些都是微服务设计要解决的问题，但是很久以来都没有一套系统的理论和方法可以指导微服务的拆分，综合来看，我认为微服务拆分困境产生的根本原因就是不知道业务或者微服务的边界到底在什么地方。换句话说，确定了业务边界和应用边界，这个困境也就迎刃而解了。
DDD 核心思想是通过领域驱动设计方法定义领域模型，从而确定业务和应用边界，保证业务模型与代码模型的一致性。
领域驱动设计是一种以业务为导向的软件设计方法和思路。我们在开发前，通常需要进行大量的业务知识梳理，而后到达软件设计的层面，最后才是开发。而在业务知识梳理的过程中，我们必然会形成某个领域知识，根据领域知识来一步步驱动软件设计，就是领域驱动设计的基本概念。而领域驱动设计的核心就在于建立正确的领域驱动模型。
1、DDD 包括战略设计和战术设计两部分。a、战略设计主要从业务视角出发，建立业务领域模型，划分领域边界，建立通用语言的限界上下文，限界上下文可以作为微服务设计的参考边界。
b、战术设计则从技术视角出发，侧重于领域模型的技术实现，完成软件开发和落地，包括：聚合根、实体、值对象、领域服务、应用服务和资源库等代码逻辑的设计和实现。
很多 DDD 初学者，学习 DDD 的主要目的，可能是为了开发微服务，因此更看重 DDD 的战术设计实现。殊不知 DDD 是一种从领域建模到微服务落地的全方位的解决方案。
战略设计时构建的领域模型，是微服务设计和开发的输入，它确定了微服务的边界、聚合、代码对象以及服务等关键领域对象。领域模型边界划分得清不清晰，领域对象定义得明不明确，会决定微服务的设计和开发质量。没有领域模型的输入，基于 DDD 的微服务的设计和开发将无从谈起。因此我们不仅要重视战术设计，更要重视战略设计。
2、DDD的优势 接触到需求第一步就是考虑领域模型，而不是将其切割成数据和行为，然后数据用数据库实现，行为使用服务实现，最后造成需求的首肢分离。DDD让你首先考虑的是业务语言，而不是数据。重点不同导致编程世界观不同。DDD可以更加领域模型界限上下文边界快速拆分微服务，实现系统架构适应业务的快速变化，例如：系统的用户量并发量增长得很快，单体应用很快就支持不了，如果我们一开始就采用DDD领域驱动设计，那我们就能很快的把服务拆分成多个微服务，以适应快速增长的用户量。DDD 是一套完整而系统的设计方法，它能带给你从战略设计到战术设计的标准设计过程，使得你的设计思路能够更加清晰，设计过程更加规范。使用DDD可以降低服务的耦合性，让系统设计更加规范，即使是刚加入团队的新人也可以根据业务快速找到对应的代码模块，降低维护成本。DDD 善于处理与领域相关的拥有高复杂度业务的产品开发，通过它可以建立一个核心而稳定的领域模型，有利于领域知识的传递与传承。DDD 强调团队与领域专家的合作，能够帮助你的团队建立一个沟通良好的氛围，构建一致的架构体系。DDD 的设计思想、原则与模式有助于提高你的架构设计能力。无论是在新项目中设计微服务，还是将系统从单体架构演进到微服务，都可以遵循 DDD 的架构原则。 3、DDD设计原则 要领域驱动设计，而不是数据驱动设计，也不是界面驱动设计。要边界清晰的微服务，而不是泥球小单体。要职能清晰的分层，而不是什么都放的大箩筐。要做自己能 hold 住的微服务，而不是过度拆分的微服务。 4、微服务拆分需要考虑哪些因素？理论上一个限界上下文内的领域模型可以被设计为微服务，但是由于领域建模主要从业务视角出发，没有考虑非业务因素，比如需求变更频率、高性能、安全、团队以及技术异构等因素，而这些非业务因素对于领域模型的系统落地也会起到决定性作用，因此在微服务拆分时我们需要重点考虑它们。我列出了以下主要因素供你参考。
4.1、基于领域模型基于领域模型进行拆分，围绕业务领域按职责单一性、功能完整性拆分。
4.2、基于业务需求变化频率识别领域模型中的业务需求变动频繁的功能，考虑业务变更频率与相关度，将业务需求变动较高和功能相对稳定的业务进行分离。这是因为需求的经常性变动必然会导致代码的频繁修改和版本发布，这种分离可以有效降低频繁变动的敏态业务对稳态业务的影响。
4.3、基于应用性能识别领域模型中性能压力较大的功能。因为性能要求高的功能可能会拖累其它功能，在资源要求上也会有区别，为了避免对整体性能和资源的影响，我们可以把在性能方面有较高要求的功能拆分出去。
4.4、基于组织架构和团队规模除非有意识地优化组织架构，否则微服务的拆分应尽量避免带来团队和组织架构的调整，避免由于功能的重新划分，而增加大量且不必要的团队之间的沟通成本。拆分后的微服务项目团队规模保持在 10～12 人左右为宜。
4.5、基于安全边界有特殊安全要求的功能，应从领域模型中拆分独立，避免相互影响。
4.6、基于技术异构领域模型中有些功能虽然在同一个业务域内，但在技术实现时可能会存在较大的差异，也就是说领域模型内部不同的功能存在技术异构的问题。由于业务场景或者技术条件的限制，有的可能用.NET，有的则是 Java，有的甚至大数据架构。对于这些存在技术异构的功能，可以考虑按照技术边界进行拆分。
5、其他 效率问题虽然DDD有这么多明显的优势，但也不是所有的系统都适合采用DDD领域驱动设计。
如上图是两层架构、多层SOA架构与DDD随着业务复杂度的增加在开发成本上的比较，可以看到刚开始DDD的成本是最高的，所以，如果是简单的系统，后续业务不会有太大变化，那么久不适合用DDD，合适才是最好的。
DDD 战术设计对设计和开发人员的要求相对较高，实现起来相对复杂。不同企业的研发管理能力和个人开发水平可能会存在差异。尤其对于传统企业而言，在战术设计落地的过程中，可能会存在一定挑战和困难，我建议你和你的公司如果有这方面的想法，就一定要谨慎评估自己的能力，选择最合适的方法落地 DDD。