引言
从2016年开始使用微服务开发，在这之前也接触过。我个人感触是微服务的思想是为了解决系统的业务复杂度，解决产品的快速迭代,实现更高效的敏捷开发。
随着微服务的应用越来越多，那么微服务相关的技术框架也相继出现，比如SpringCloud Alibba,SpringCloud Netflix 等等。对应技术框架版本也相应地每年都有更新升级。微服务技术框架几个核心的技术件，配置中心，网关服务，注册中心，监控服务，日志服务，事件总线等都是需要掌握的。
微服务是一种设计思想，是将产品业务服务进行水平拆分，拆分成并行的多个业务领域；垂直拆分，将每一个业务进行模块分层，实现模块的职责聚焦，提高合成复用率。
现在越来越多的是分布式微服务,实现提高服务的高并发，高可用，高性能，有时候在企业负责的眼里还需高效迭代(高可维)。这都是作为资深技术开发所需要取掌握并进行理解的解决方案。另外分布式微服务所带来的技术上的复杂度，分布式锁，分布式事务，服务之前的协同等都是需要解决问题
什么是DDD
产生出一种新的思想一般都是为了解决已经产生的一些问题，DDD的出现就是为了解决微服务的落地实现过程中的问题。微服务的目的就是为了拆分业务，来降低复杂度。那么怎么拆，按照什么样的模式去拆？DDD就是为了解决这个而提出来。
DDD是一种设计理论，准确的说是为微服务的实现提供了 一套理想的解决方案。在这个理论上驱使下认为将业务分解成多个独立的业务域,每一个业务域可以有多个领域服务去完成业务。而这些领域的协作和沟通，有专门的语言或者描述统一。这样就解决多个行业的跨职业沟通的障碍问题，使得信息可以共享，对于业务理解达到高度一致。以这个为前提下，技术架构师和业务架构师所拆解的领域分布和领域服务可以是完全接近于实际需求的。
DDD的实现方法论
领域驱动设计是提供了一种解决问题的方法，提出这种方法的时候也给我设想了这个方法所能达到或者实现的某种结果。那么在这个过程中，做事的方法会有很多种，我根据个人经历总结如下方法：
-
统一语言,提升团队间的沟通效率
软件开发设计的有技术部，产品部，测试部，VP,运营人员，这些人都很熟悉自己的职业范围内的逻辑。想让这么多部门人员能统一沟通，达到信息能更想，肯定需要有专业业务术语和技术术语以及共识的符号来来表达我们的想法，为后续的建模做准备
-
事件风暴,收集业务产品信息
收集所有可用的跟业务产品相关的信息，与各个业务一线人员取经，了解业务的诉求(切记不是需求)梳理业务信息，然后列举所有有效的跟业务产品相关的能力场景，总结出业务领域对象和关系
-
限界上下文
限界上下文这个是在各个场景下发生的事件，所需要关注的关联的信息。然后把这些信息根据业务模块进行定义分类，形成业务领域，每隔领域内都有专门的上下文来识别和描述业务领域。最后形成统一的业务模块和业务领域
-
领域事件
上下文完成了领域内相关的信息的定义，那么领域之间的信息的传递的和业务完成都要依赖于各个领域发生的事件。这些事件就是影响各个业务状态的流转和逻辑变更的关联关系的结果。这些事件的处理过程就是我们在代码实现中要重点设计和关注的
-
构建业务领域模型
模型的构建是要在进入项目开发之前就应该去完成的，建模的过程就是把一件复杂庞大的事情进行规范化，可视化。实际他也是一个规范，规范业务边界，业务概念的定义，从而提炼出模型。大家也会去按照这个实行，遵守规范。使得大家实现的目标达成一致。
-
业务领域分析验证
很多设计者在完成了上面的任务就觉得设计任务完成了。但是在做过项目都会发现，你开始设计的再完美，到最后都会发现实际都会与想象的不一样。所以在做完模型建设之后，还需要对这些完成的事务与时间风暴的内容进行一一验证。验证模型的定义是否准确，边界是否清晰，主体的业务流程和领域是否是完全完整的。对于完整性的这个定义我会在自己的其他文章分析
-
微服务的拆分设计
完成了以上的步骤之后就是怎么去对自己的领域服务进行规划，拆分。拆分的原则，基本就是遵循设计六大原则：
单一职责-----------业务领域模块功能一定是干净的，不会有穿插的
依赖倒置-----------业务领域，支撑域，主题域，公共域的依赖关系要明确
接口隔离-----------业务领域完成的功能提供的出去的API一定是统一的
开闭原则-----------所有的API完成的功能一定是可扩展但是不能修改
里氏替换-----------这个属于再扩展的基础之上，业务领域模块之前耦合度控制
总结
DDD是一种设计方法，大家在学习过程中，不能以固定方法去套用，而是应该以他所提出的理论为目标，在完成这个目标过程中去理解，去思考。从而达到优雅的微服务设计