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

本文重点说明了领域建模的落地实践方法，通过领域建模能够帮助我们很好的识别业务、理清影响、对其认知，更好的消化业务复杂度；通过时间风暴、命令风暴、寻找聚合、用例分析等过程，帮助我们更好对也进行建模的。

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

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

架构这个词源于英文里的“Architecture“，源头是土木工程里的“建筑”和“结构”，而架构里的”架“同时又包含了”架子“（scaffolding）的含义，意指能快速搭建起来的固定结构。而今天的应用架构，意指软件系统中固定不变的代码结构、设计模式、规范和组件间的通信方式。在…

导读：对于一个架构师来说，在软件开发中如何降低系统复杂度是一个永恒的挑战，无论是 94 年 GoF 的 Design Patterns ， 99 年的 Martin Fowler 的 Refactoring ， 02 年的 P of EAA ，还是 03 年的 Enterpri…

在项目的开发阶段，目录结构的划分往往被看做是迈向成功的第一步。这一步的迈出往往伴随着很多方面的权衡（考量），总的来说是两个方面的考量：业务方面和技术方面。 业务方面的考量包括：限界上下文、子域、业务模块。 技术方面的考量包括：软件架构（分层架构、六边形架构）、构造型分类。 常见…

DDD领域驱动不是架构，而是一种架构设计方法论。 在当今以微服务为主流的环境下，很多时候我们在拆分微服务的时候，往往是根据直觉、经验对服务进行拆分，比如订单服务、用户服务、支付服务。 但这些服务只是将传统的单体架构拆分为了多个单体架构，当某一个服务的业务经过长期发展，业务越来越…