在一个DDD架构设计中，领域层的设计合理性会直接影响整个架构的代码结构以及应用层、基础设施层的设计。但是领域层设计又是有挑战的任务，特别是在一个业务逻辑相对复杂应用中，每一个业务规则是应该放在Entity、ValueObject 还是 DomainService是值得用心思考的，既要避免未来的扩展性差，又要确保不会过度设计导致复杂性。今天我用一个相对轻松易懂的领域做一个案例 […]

​​了解过 Hex 六边形架构、Onion 洋葱架构、Clean 整洁架构的同学可以将本篇文章介绍的实践方法与自身项目代码架构对比并互通有无，共同改进。没了解过上述架构的同学可以学习一种新的架构方法，并尝试将其应用到业务项目中，降低项目维护成本，提高效率。 ​ ​本文提及的架构主要指项目组织的“代码架构”，注意与微服务架构等名词中的服务架构进行区分。   1.为什 […]

作者|殷浩 出品|阿里巴巴新零售淘系技术部 写在前面： 这篇文章和《阿里技术专家详解DDD系列 第二弹 - 应用架构》隔了比较久，一方面是工作比较忙，另一方面是在讲Repository之前其实应该先讲Entity（实体）、Aggregate Root（聚合根）、BoundedContext（限界上下文）等概念。但在实际写的过程中，发现单纯讲Entity相关的东西会比较抽象， […]

作者|殷浩 出品|阿里巴巴新零售淘系技术部 架构这个词源于英文里的“Architecture“，源头是土木工程里的“建筑”和“结构”，而架构里的”架“同时又包含了”架子“（scaffolding）的含义，意指能快速搭建起来的固定结构。而今天的应用架构，意指软件系统中固定不变的代码结构、设计模式、规范和组件间的通信方式。在应用开发中架构之所以是最重要的第一步，因为一个好的架构 […]

写在最前面 对于一个架构师来说，在软件开发中如何降低系统复杂度是一个永恒的挑战，无论是94年GoF的Design Patterns，99年的Martin Fowler的Refactoring，02年的P of EAA，还是03年的Enterprise Integration Patterns，都是通过一系列的设计模式或范例来降低一些常见的复杂度。但是问题在于，这些书的理念是 […]

向读者们道歉，由于工作太忙，又对文章质量有追求，所以这篇文章产出速度较慢，但可以向大家保证：文章中的内容都经过了反复实践和踩坑。DDD系列的前几篇文章可以点击文字下方阅读~ DDD系列第一讲 DDD系列第二讲 DDD系列第三讲 DDD系列第四讲 在过去一年里我们团队做了大量的老系统重构和迁移，其中有大量的代码属于流水账代码，通常能看到是开发在对外的API接口里直接写业务逻辑 […]