关键词：
摘要
前面两篇介绍了DDD的目标管理、DDD的工程结构调整。这篇讨论微服务的划分。微服务是目前后端比较流行的架构体系了，那么如何做好一个微服务的划分？一个微服务的粒度应该是多大呢？这篇主要介绍如何结合DDD进行领域划分。
工程结构代码
上篇介绍了可落地的DDD的(2)-为什么说MVC工程架构已经过时
很多朋友留言说，有没有sample code，要不然太湿了，不是很明白。这里写了个sample。
就以一个博客网站为例
page1:博客列表页： 展示所有用户发表的博客
page2: 个人介绍页：有个人简介和博客列表
page3：博客详情页.
不同的业务展示的用户/博客的字段不一致
建模
后期应该会有用户和博客交互的需求。这期只有用户创建博客这层关联关系。
MVC架构
使用mvc模式写出来的代码，就是一路到底。
具体代码见mvc-structure
DDD
使用DDD写出来的工程结构就是，blog和user的交互只有一个地方，OpenXXXService
具体代码见DDD structure
MVC VS DDD
从两张依赖图可以看出，DDD的依赖图清晰了，user和blog这两个领域之间的交互变的清晰了，user这个领域不用管blog领域发生了什么变更。只依赖OpenBlogService，而MVC模式呢，user和blog之间的交互太多了，如果再增加其他功能，这些模块之间就是够筹交错，理不清楚。
不同领域之间的交互多了，意味着一旦发生变更，需要修改逻辑了，那么需要修改的地方就是几何倍数的相关类。
比如业务发生了变更，统计【个人中心】的博客计数是用户已发表的文章。而这个已发表的可能随着业务的发展，包含多重含义
- 用户写完了，对外开放了，
- 运营审核通过
- 博客未被软删除的。
这些逻辑都会影响相关的查询，而这些逻辑的实现可能在数据库层面做，可能在redis中做，或者其他的方式。以MVC的写法，需要的需要修改的地方很多，以DDD的方式，不管这个逻辑怎么变，其他领域不需要知道，只有blog领域知道，只用更改blog领域的代码。
微服务划分
初版
确定了以DDD作为我们领域划分的指导原则后，我们首先按照领域对我们的业务进行了全面的分析，区分出哪些领域。然后按照如下标准进行了微服务的拆分
- 一个领域一个服务的规则去拆分，
- 同时为了保证领域的纯洁性，我们区分了领域服务，和前台服务。领域服务就是领域逻辑，不直接对前端暴露。前台服务组装各个领域服务，暴露给前端。
- 同时为了保持扩展，我们预留了一个微服务作为服务孵化器。对于领域不清晰的（比如大部分的新的业务），放在这个服务里面孵化，然后等领域足够大的时候再拆分出去。
如下图
前台应用：
pc: pc端的页面展示
mobile: 移动端的页面展示
mini：小程序的页面展示
领域服务：
blog: 博客领域
user: 用户领域
growth: 领域孵化器
按照这样的标准去拆分后，一段时间后，很多问题暴露了。
服务热点问题
我们是一个新的业务，在业务迭代的过程中，大部分新需求都是领域不清晰，不知道能不能迭代下去的。所以按照之前的标准，都往growth服务里面去写代码，这样导致几乎团队里面的所有的人都在开发这一个项目，失去了拆分微服务的意义。服务依赖太严重
无论写什么需求，都需要写多个应用，领域服务1个，前台如果有pc,需要在pc服务上开发，移动端要展示，要在mobile服务开发。服务之间的调用需要写rpc client接口，需要发版本，因为同时开发的人多，经常发生版本混乱，依赖问题。服务上线也很头疼，改一个小需求，需要部署多个服务。微服务一个很重要的点是去耦合，可独立部署。多了一层UI层作为微服务显然不是很合适。领域划分有问题
一个领域一个服务，粒度太小，有些东西不知道放在哪个服务里面，比如用户收藏博客，是放在用户服务里面，还是放在博客领域呢。
如何解决
不拆分单体应用不知道，一拆分问题一大堆。那么我们是怎么解决的呢？下期再见。
相关阅读
可落地的DDD(1)-目标讨论
可落地的DDD的(2)-为什么说MVC工程架构已经过时
关注【方丈的寺院】，第一时间收到文章的更新，与方丈一起开始技术修行之路
微服务如何划分(代码片段)
...行微服务的划分呢?在以前的文章中讨论过这个话题，可落地的DDD(4)-如何利用DDD进行微服务的划分(2)[1]，最近结合在不同的开发团队实践，又有了新的思考，相比较之前的基于DDD会更加全面可落地，也欢迎大家留言讨论。为何要... 查看详情
ddd领域驱动设计落地实践系列：微服务拆分之道
引言在前面的两篇文章中，笔者给大家介绍了DDD核心思想、重要概念以及如何进行DDD进行微服务实践的大致过程，后续的文章中将逐渐深入DDD的实践细节，包括领域模型与代码模型的映射以及具体的微服务设计实例等... 查看详情
ddd领域驱动设计落地实践系列：初识ddd
...系列的文章阐述自己对于DDD的理解以及如何在项目实战中落地实践DDD。本文作为系列文章的开端，主要和大家聊聊DDD的一些基本概念以及常用方法。 查看详情
ddd专栏7：ddd如何指导微服务设计实现
...服务技术架构的学习上。然而，当他们真正开始将微服务落地到具体的业 查看详情
ddd领域驱动设计落地实践系列：战略设计和战术设计
...实现微服务划分等提供了方向和指导。但是对于如何具体落地使用DDD，可能大家还是一脸懵B的状态，因此从本文开始以及后面的文章将对如何进行DDD落地进行详细的阐述。在这其中还是会涉及到DDD中的一些重要概念，... 查看详情
ddd的理解
...动设计:是一种设计思想,应用到IT技术领域,主要是指导微服务设计和划分的思想.DDD强调通过领域驱动设计方法定义领域模型,确定业务和应用的边界,保证业务模型和代码模型的一致性.DDD通过建立领域模型 --> 划分领域边界 --&... 查看详情
可落地的ddd-战术设计上的一些误区
背景几年前我总结过DDD战术设计的一些落地经验可落地的DDD(5)-战术设计，和一次关于聚合根的激烈讨论最近两年有些新的落地体验，回过头来发现，当初对这些概念的理解还是没有深入，这篇文章重新阐述下。之... 查看详情
可落地的ddd-战术设计上的一些误区
背景几年前我总结过DDD战术设计的一些落地经验可落地的DDD(5)-战术设计，和一次关于聚合根的激烈讨论最近两年有些新的落地体验，回过头来发现，当初对这些概念的理解还是没有深入，这篇文章重新阐述下。之... 查看详情
ddd专栏6：建模演练：如何使用ddd来设计支付风控系统？
...计出"高内聚、低耦合"的高质量软件，希望你能够对DDD的落地实践有个完整的蓝图，并能够在一些具体项目中大胆的进行实践，来完善DDD的其他细节。同时上一讲中也提到了，当应用进入微服务阶段，DDD将会体现出更大的作用... 查看详情
可落地的ddd-工程结构
背景几年前我在可落地的DDD的(2)-为什么说MVC工程架构已经过时总结了基于DDD的微服务工程结构是怎么样的。那篇文章重点阐述了与MVC架构的区别。导致一些细节没有讲清楚，本文结合最近两年的实践，再详细阐述下。应... 查看详情
ddd核心概念与domainprimitive(代码片段)
...边界，定义领域模型，确定业务边界。在微服务落地时，建立业务领域模型与微服务代码模型的映射关系，从而保证业务架构与微服务系统架构的—致性。但DDD提出后在软件开发领域一直都是“雷声大雨点小”... 查看详情
ddd如何设计落地？（库存，产品账示例）
一. 背景 本文以预算管控服务建设作为一个DDD设计的例子介绍，目标是是呈现一次DDD设计的过程，为了减少绘图和描述的工作量，文中会对预算管控业务需求和功能做简化。请重点关注设计的流程，这是我... 查看详情
ddd领域驱动设计-ddd概览
...通过领域建模的方式去设计我们的软件程序。-那么领域如何驱动设计？或者说业务如何驱动设计？传统开发过程我们都是基于面向数据开发，拿到产品原型脑海里想着都是应该创建哪些表和哪些字段才能满足需求。而领域驱动... 查看详情
可落地的ddd-战术设计上的一些误区
几年前我总结过DDD战术设计的一些可落地的经验，现在回过头来发现，当初对这些概念的理解还是没有到位。比如战术设计的各个模块是如协作的。哪些是问题空间问题，哪些是解方案空间问题这篇文章重新阐述下。几年前我总... 查看详情
实践篇教你玩转微服务--基于ddd的微服务架构落地实践之路
作者：京东物流赵勇萍一.前言现在对于一个后端开发工程师来说，微服务，DDD都是挂在嘴边的东西，感觉大家接触到多，也了解的多。但笔者个人的感受是，对微服务架构的理解就像我小时候读三国，在不同年龄读的时候感触... 查看详情
ddd专栏11微服务时代，单体架构淘汰了吗？
...是还只介绍了菱形架构是什么，还没有介绍菱形架构到底如何指导程序设计。这一讲，我们将通过讲解菱形架构之间如何协 查看详情
可落地的ddd-工程结构
背景几年前我在可落地的DDD的(2)-为什么说MVC工程架构已经过时总结了基于DDD的微服务工程结构是怎么样的。那篇文章重点阐述了与MVC架构的区别。导致一些细节没有讲清楚，本文结合最近两年的实践，再详细阐述下。应... 查看详情
可落地的ddd-工程结构
背景几年前我在可落地的DDD的(2)-为什么说MVC工程架构已经过时总结了基于DDD的微服务工程结构是怎么样的。那篇文章重点阐述了与MVC架构的区别。导致一些细节没有讲清楚，本文结合最近两年的实践，再详细阐述下。应... 查看详情