在我看来并不是MVC的基础上增加领域层，使用充血模型，解耦基础服务，我的代码就符合DDD了。   为什么要使用DDD？   DDD分为战略部分跟战术部分，相信大家都认同DDD的核心在战略而非战术。而战略方面的核心我认为在业务建模，领域划分、统一语言等都在为业务建模服务。 为什么业务建模重要? 以前的开发流程有什么问题？ 先说结论，开发人员交付的程序对业务方，产品人员，测 […]

书籍信息 书名：《解构领域驱动设计》 作者：张逸 开篇 软件复杂度剖析 复杂系统 复杂系统：由大量互相作用的部分组成的系统。这些组成部分相对简单，没有中央控制，组成部分之间也没有全局性的通信，并且组成部分的相互作用导致了复杂行为。 理解能力 影响阻碍理解能力的要素： 规模 结构 预测能力 影响阻碍预测能力的要素： 过度设计 设计不足 领域驱动设计概览 基本概念 软件系统的构 […]

一、传统分层架构 分层架构的一个重要原则是：每层只能与位于其下方的层发生耦合。 分层架构分两种：一种是严格分层架构，规定某层只能与直接位于其下方的层发生耦合；另一种是松散分层架构，允许任意上方层与任意下方层发生耦合。 下图是一个典型的DDD传统分层架构。 以上分层架构中各层都有自己的职责： 用户接口层负责处理用户请求和用户显示； 应用层实现不同业务场景下的用例或业务流程。其 […]

  对于一个架构师来说，在软件开发中如何降低系统复杂度是一个永恒的挑战。 01 为什么需要DDD 复杂系统设计：系统多，业务逻辑复杂，概念不清晰，有什么合适的方法帮助我们理清楚边界，逻辑和概念 多团队协同：边界不清晰，系统依赖复杂，语言不统一导致沟通和理解困难。有没有一种方式把业务和技术概念统一，大家用一种语言沟通。例如：航程是大家所理解的航程吗？ 设计与实现一致 […]

导读 本文将对测试驱动开发（TDD）进行探讨，主要阐述了TDD基本概念理解、TDD常见误区、TDD技术选型等，并提供了贫血模型三层架构和DDD下的TDD实战案例。   01 前言 领域驱动设计，测试驱动开发。 《手把手教你落地DDD》一文中介绍了领域驱动设计（DDD）的落地实战，本文将对测试驱动开发（TDD）进行探讨，主要内容有：TDD基本理解、TDD常见误区、T […]

导读 本文将从日常的三层架构出发，精炼推导出自己的应用架构，并且将这个应用架构实现为Maven Archetype，最后使用Archetype创建一个简单的CMS项目作为本文的落地案例。   01 前言 在今年的敏捷团队建设中，我通过Suite执行器实现了一键自动化单元测试。Juint除了Suite执行器还有哪些执行器呢？由此我的Runner探索之旅开始了！ 常见 […]

  过去几年，通天塔一直处于快速的业务能力建设和架构完善的阶段，以应对不断增长的业务需求和容量、高可用等技术需求，现在通天塔平台已经能满足集团主站的大部分活动、频道搭建和运营能力，主流程的新需求越来越少，个性化需求和非标准化流程的数据源和服务接入的需求越来越多，有些甚至是京东零售体系外的，同时通天塔技术和产品也在积极主动寻求变化和创新，这些因素结合在一起驱动通天塔 […]

前言 至少30年以前，一些软件设计人员就已经意识到领域建模和设计的重要性，并形成一种思潮，Eric Evans将其定义为领域驱动设计（Domain-Driven Design，简称DDD）。在互联网开发“小步快跑，迭代试错”的大环境下，DDD似乎是一种比较“古老而缓慢”的思想。 然而，由于互联网公司也逐渐深入实体经济，业务日益复杂，我们在开发中也越来越多地遇到传统行业软件开 […]

作者：欧创新、邓頔、文艺 你是否还在为微服务应该拆多小而争论不休？到底如何才能设计出收放自如的微服务？怎样才能保证业务领域模型与代码模型的一致性？或许本文能帮你找到答案。 本文是基于 DDD 的微服务设计和开发实战篇，通过借鉴领域驱动设计思想，指导微服务项目团队进行设计和开发（理论篇详见《当中台遇上 DDD，我们该如何设计微服务？》）。本文包括三部分内容：第一部分讲述领域驱 […]

在一个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接口里直接写业务逻辑 […]