前文回顾 上一篇介绍了该书的第二部分“模型驱动设计的构造块”，将面向对象领域建模中的一些核心的最佳实践提炼为一组基本的构造块。我们在一个模拟的场景中，运用学到的建模知识，处理了假象的需求，并对模型进行

先说声抱歉，最近两三个星期都没有产出新的文章了。一方面是忙(懒)；另一方面是在想能写什么题材，毕竟日常开发中遇到能写的问题其实不多。 恰好最近参加了公司的DDD（领域驱动设计）培训，再加上自己目前项目上也是使用的DDD，半年来大家也遇到过一些坑。所以打算写一些DDD方面的文章，…

当我们设计一个订单模块，用户下单时，我们需要确保用户的余额可供支付这笔订单，并且保存这个订单。通俗的理解就是当下单的时候，必须生成订单表记录，并且检查用户余额是否足够支付，并修改用户的余额表。再转换到我们领域驱动设计中，我们必须利用订单模型和账户模型联合来完成操作，并检查保证业…

实体最主要有两点特征，一是唯一标识，二是连续性。 当一些对象不是由属性定义，而是由一个唯一标志定义的话，我们就可以认为它是一个实体。好比我们不能通过一个人的外在特征去唯一定位一个人，因为人从小到大，从年轻到衰老其外在特征都是在改变的。而身份证号码可以贯穿一个人的一生而不发生变化…

在很多的微服务开发团队在设计和实现微服务的时候觉得只要把原来的单体拆小，就是微服务了。但是这不一定是正确的微服务，可能只是一个拆小的小单体。这篇文章让我们从这个话题继续，先看看为什么拆出来的是小单体。 在微服务架构诞生之前，几乎所有的软件系统都是采用单体架构来构建的，因此大部分…

在实践领域驱动设计（DDD）的过程中，我们会根据项目的所在领域以及需求情况捕获出一定数量的领域对象。设计得足够好的领域对象便于我们更加透彻的理解业务，方便系统后期的扩展和维护，不至于随着需求的扩展和代码量的累积，系统逐渐演变为大泥球（Big Ball of Mud）。 虽然领域…

假设我们在设计订单模型时，下单操作涉及到会员等相关规则，比如增加积分等操作。（此时我们还未将订单子域和会员子域进行剥离）。其实一个用户的下单操作不需要与会员的积分产生强烈耦合。一旦会员的积分制度发生变动，又得需要在订单子域中进行修改，而订单子域又是我们的核心域，频繁的对核心域进…

DDD即Domain Driven Design，翻译成中文的话就是领域驱动设计，首先我们应该先理解这里的领域是什么意思？假设公司内部正在开发一套电商平台，而电商平台中包含了库存、订单、商品等核心业务。这些核心业务逻辑其实呈现的就是电商平台领域。通俗的理解就是一整套体系的业务知…

前面两篇介绍了DDD的目标管理、DDD的工程结构调整。这篇讨论微服务的划分。微服务是目前后端比较流行的架构体系了，那么如何做好一个微服务的划分？一个微服务的粒度应该是多大呢？这篇主要介绍如何结合DDD进行领域划分。 很多朋友留言说，有没有sample code，要不然太湿了，不…