本文是「后端开发实践系列」的第二篇，主要介绍了DDD中的应用服务、聚合、资源库和工厂等概念以及与它们相关的编码实践，更着重讲到了软件的读写操作在DDD中的实现方式。

一.前言 hello，everyone。 昨天在掘金看到了这么一篇文章：拥抱毒瘤 DDD！ 鄙人不才，近期在做DDD落地，并且也发了几篇系列文章，在github上也上传了demo 看到他写的喷文，我直

我在最近一年经常听到大家在讨论DDD，而且议论纷纷，大家各抒己见。 比如说在某技术微信群讨论，有些人说DDD是噱头，为了搞个业绩（又不是不能跑 😉），还有些表示自己是CRUD Boy 不知道DD

分享自 GitHub

大家好，我是楼仔！ 去年倒腾了一个半月，写过一篇 DDD 的文章，当时没有推广，完全自嗨，为了不让这篇好文被埋没，现重新整理，突出重点，可读性更强！ 为了证明该文没有注水，列一下当时的学习资料： 小米

本文将带领大家从日常的三层架构出发，精炼推导出我们自己的应用架构，并且将这个应用架构实现为Maven Archetype，最后使用我们Archetype创建一个简单的CMS项目作为本文的落地案例。

在过去一年我们团队做了大量老系统重构和迁移，其中有大量代码属于流水账代码，通常能看到是开发在对外的API接口里直接写业务逻辑代码，或者在一个服务里大量的堆接口，导致业务逻辑实际无法收敛。

在一个DDD架构设计中，领域层的设计合理性会直接影响整个架构的代码结构以及应用层、基础设施层的设计。但是领域层设计又是有挑战的任务，特别是在一个业务逻辑相对复杂应用中，每一个业务规则是应该放在Entity、ValueObject 还是 DomainService是值得用心思考的…

这篇文章和《阿里技术专家详解DDD系列 第二弹 - 应用架构》隔了比较久，一方面是工作比较忙，另一方面是在讲Repository之前其实应该先讲Entity（实体）、Aggregate Root（聚合根）、Bounded Context（限界上下文）等概念。但在实际写的过程中，…