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

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

本文目录 - 说在前面 - 《殷浩详解DDD：领域层设计规范》正文   - 从技术视角出发， 探索如何降低软件复杂性   - 从业务视角出发， 探索如何降低软件复杂性   - 业务视角的设计方法论和技

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

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

DDD从来就没有什么固定的框架，也从来没有限定于JAVA或某种特定语言。如果有，那大概是因为有人要拿结果，有人要成名，还有人要牟利，人为把它复杂化。