预算管控服务(库存和产品账平台)的DDD设计案例
一. 背景 本文预算管控服务建设作为一个DDD设计的例子介绍，目标是是呈现一次DDD设计的过程，为了减少绘图和描述的工作量，文中会对预算管控业务需求和功能做简化。请重点关注设计的流程，这是我们想传达的重点，忽略设计细节的合理性。另外，对于预算管控服务来讲，不一定要用DDD来进行分析设计，基于传统的数据驱动就完全可以满足需求，但作为介绍DDD实施过程，预算管控是一个不错的例子（不需要画太多的
深入理解领域驱动设计中的聚合
聚合模式是 DDD 的模式结构中较为难于理解的一个，也是 DDD 学习曲线中的一个关键障碍。合理地设计聚合，能清晰地表述业务一致性，也更容易带来清晰的实现，设计不合理的聚合，甚至在设计中没有聚合的概念，则相反。
提升代码质量的方法：领域模型、设计原则、设计模式
我们可以列举出非常多质量差的代码的表现现象，其中最影响代码质量的两个表现是命名名不副实、逻辑可扩展性差，当一个新人阅读代码时，有时发现方法命名与实际逻辑对不上，这就让人感到非常疑惑，这种现象在平时工作并不少见；另一个就是逻辑扩展性差，一个新业务需求提出来后，发现要在多处改动，需要回归的业务逻辑比较多，造成研发效率不高。
从单体架构到微服务架构
微服务的优势众多，在现在如果有谁没有听过微服务架构，可以从这里了解一下。本文主要聊一聊是否值得花时间将单体架构重构为微服务架构？
业务团队如何形成统一的设计风格
首次上线应用，面对业务框架搭建你是否曾感到无从下手？维护线上应用，面对大量历史包袱你是否正避坑不及深陷泥潭？为何同样是业务应用，不同人的设计风格千差万别？为何最初的设计经过多个迭代后总是面目全非？新人来到团队，怎样才能快速了解业务，不被大量技术细节折磨？如果你也有这些困扰，希望本文能提供些许帮助。
案例教你一步步设计DDD微服务项目（上）
DDD战略设计从事件风暴开始，然后我们要找出实体等领域对象，找出聚合根构建聚合，划分限界上下文，建立领域模型。
战术设计从事件风暴的命令开始，识别和设计服务，建立各层服务的依赖关系，设计微服务内的实体和值对象，找出微服务中所有的领域对象，并建立领域对象与代码对象的映射关系。
