Larry的博客

DDD中的聚合设计

业务流程和领域模型构成业务系统的核心要素，业务流程升级到业务价值流，领域模型升级到企业级业务对象，这就变成了企业架构的方法（价值流+业务能力+业务对象），所以DDD和企业架构方法是相通的，一个是微观，一个是宏观，两者结合可以更好的认识数字化建设。最后预告下篇内容，上代码模型。

领域驱动设计（Domain-driven design，DDD）是一种为复杂需求开发软件的方法，它将软件的实现与不断发展的核心业务概念模型紧密地结合在一起。

目录DDD为什么能火起来？微服务存在的问题DDD概述总结DDD为什么能火起来？我们先不讨论DDD的定义， 先梳理一下DDD火起来的背景， 根据我学习的套路， 永远是为什么为先，再是解决什么问题，是什么东西， 最后如何使用。我们都知道这些年随着设备以及技术的发展，软件架构发生了很多变化，从最初的单机(BS/CS)架构到后面的集中式架构，再到如今的微服务架构， 现在基本可以说是微服务架构盛行的时代， DDD早在2004年就由埃里克·埃文斯提出， 但一直处于一个不愠不火的状态，直到Ma

本文转自：架构师目录前言领域驱动设计和有界上下文微服务与有限上下文如何相关上下文映射—精确划分微服务边界的一种方法重新定义服务边界—将聚合映射到正确的上下文事件风暴-识别服务边界的另一种技术微服务之间的通信围绕最终一致性设计应用程序支持事件驱动的架构避免针对特定消费者数据需求的服务之间的编排前端的后端BFF结论前言尽管微服务中的“微”一词表示服务的规模，但它并不是使用微服务的唯一标准。当团队转向基于微服务的架构时，他们旨在提高敏捷性以及自主且频

目录一、专业术语二、架构演变三、限界上下文四、领域驱动设计的四重边界五、整洁分层架构六、六边形架构七、洋葱架构八、总结我们生活中都听说了DDD，也了解了DDD，那么怎么将一个新项目从头开始按照DDD的过程进行划分与架构设计呢？一、专业术语各种服务IAAS：基础设施服务，Infrastructure-as-a-servicePAAS：平台服务，Platform-as-a-serviceSAAS：软件服务，Software-as-a-service二、

本文转自：阿里巴巴中间件目录01 如何解决复杂业务设计02 领域设计01 战略建模02 战术建模03 不同场景下的领域建模策略01 新建系统02 单体遗留系统04 云原生时代下的挑战05 不要忽视组织结构的影响06 SOA-微服务-中台：妥协的艺术07 结语01 如何解决复杂业务设计软件架构设计本身就是一个复杂的事情，但其实业界已有一个共识，那就是“通过组件化完成关注点的分离从而降低局部复杂度”。其实现在我们用的无论是容器、中间件、消息、数据库等，

本文转自：阿里巴巴中间件目录背景拆分目的是什么？拆分时机应该如何决策？拆分时应该坚守哪些指导原则？拆分的粒度是不是越细越好？拆分策略有哪些？服务都拆了为什么还要合并？拆分过程中要注意的风险背景微服务在最近几年大行其道，很多公司的研发人员都在考虑微服务架构，同时，随着 Docker 容器技术和自动化运维等相关技术发展，微服务变得更容易管理，这给了微服务架构良好的发展机会。在做微服务的路上，拆分服务是个很热的话题。我们应该按照什么原则将现有的业务进行拆分？是否拆

本文转自：ThoughtworksMicroservice（微服务架构）和DDD（领域驱动设计）是时下最炙手可热的两个技术词语。在最近两年的咨询工作中总是会被不同的团队和角色询问，由此也促使我思考为什么这两个技术词汇被这么深入人心的绑定，它们之间的关系是什么呢？服务于更高的业务响应力首先从两个词汇的发明来看它们是没有因果关系的。DDD是Eric Evans于2003年出版的书名，同时也是这个架构设计方法名的起源。DDD的想法是让我们的软件实现和一个演进的架构模型保持一致，而这个演进的模型

过去几年，通天塔一直处于快速的业务能力建设和架构完善的阶段，以应对不断增长的业务需求和容量、高可用等技术需求，现在通天塔平台已经能满足集团主站的大部分活动、频道搭建和运营能力，主流程的新需求越来越少，个性化需求和非标准化流程的数据源和服务接入的需求越来越多，有些甚至是京东零售体系外的，同时通天塔技术和产品也在积极主动寻求变化和创新，这些因素结合在一起驱动通天塔孵化出了一个以技术为导向的项目：通天塔积木，旨在构建一个基于完全开放的前端 SDK 和后端数据源&服务、高度灵活和强大的积木画布、能够快速移植

以下是参考DDD战略设计和战术设计分析流程，及其相关的关键步骤，及每个步骤需要的输入，分析方法，输出的关键成果物。

本文转自：微信公众号 阿里技术导读在日常工作中我观察到，面对老系统重构和迁移场景，有大量代码属于流水账代码，通常能看到开发在对外的API接口里直接写业务逻辑代码，或者在一个服务里大量的堆接口，导致业务逻辑实际无法收敛，接口复用性比较差。所以本文主要想系统性的解释一下如何通过DDD的重构，将原有的流水账代码改造为逻辑清晰、职责分明的模块。1 案例简介这里举一个简单的常见案例：下单链路。假设我们在做一个checkout接口，需要做各种校验、查询商品信息、调用库存服务扣库存、然后生成订单：.

DDD是什么？Evans DDD2004年Eric Evans 发表Domain-Driven Design –Tackling Complexity in the Heart of Software （领域驱动设计 ）简称Evans DDD领域建模是一种艺术的技术，它是用来解决复杂软件快速应付变化的解决之道DDD定义DDD是一种设计思想，它是基于事件风暴，使用通用语言，对业务进行领域建模，通过限界上下文对业务进行合理的领域拆分，使得领域模型更好地转向微服务和落地，从而解决复杂系统难以

DDD（领取驱动设计）系列主题之基础概念对象介绍（实体，值对象，仓储等）

文章引用自： 微信架构师公众号领域和子域在很长一段时间里，我们认为技术是主导项目成功的关键因素，这种关键因素通常表现在项目使用的编程语言、框架、架构（如：分层架构）、中间件、数据库等等方面（如：生态）。但技术真的是项目成功的关键因素吗？在一个软件项目里除了技术层面的这部分，我们最主要的事情是实现业务。实现业务其实是在实现所在业务领域中所需要的业务。技术也是一个领域，称之为技术领域。领域驱动设计中的领域是指的业务领域。大多数的技术人员对技术领域中的知识比较感兴趣（狂热），因为这能够使得自.

DDD（领取驱动设计）系列主题之聚合和聚合根本篇文章主要介绍了聚合根，聚合的概念，然后介绍了聚合的设计过程和原则，以及对比了聚合，聚合根，实体，值对象的特点。思考的问题 为什么要在限界上下文和实体之间增加聚合和聚合根的概念，它们的作用是什么？ 如何设计聚合？ 概念和职责聚合根： 如果把聚合比作组织，聚合根则是组织的负责人，聚合根也叫做根实体，它不仅仅是实体，还是实体的管理者； 职责： 作为实体，具备自己的业务属性，业务行为，业务逻辑 ...

导读在 DDD 领域建模和系统建设过程中，有很多的参与者，包括领域专家、产品经理、项目经理、架构师、开发经理和测试经理等。对同样的领域知识，不同的参与角色可能会有不同的理解，那大家交流起来就会有障碍，怎么办呢？因此，在 DDD 中就出现了“通用语言”和“限界上下文”这两个重要的概念。这两者相辅相成，通用语言定义上下文含义，限界上下文则定义领域边界，以确保每个上下文含义在它特定的边界内都具有唯一的含义，领域模型则存在于这个边界之内。所以为了更好地理解限界上下文，我们先从通用语言讲起。什

DDD（领取驱动设计）系列主题之失血模型，贫血模型与充血模型

在DDD的项目实践中，我们会使用一些常用的架构模式，来进行系统架构的合理设计。　以下是DDD常用架构模式：DDD分层架构 整洁架构 六边形架构 DDD分层架构 vs 整洁架构 vs 六边形架构 Event Driven 架构 CQRS(Command Query Responsibility Segregation) 架构 微服务内领域事件设计模式 微服务间领域事件设计模式 DDD分层架构DDD 分层架构包含用户接..

目录阶段一：识别业务领域和子域及其类型阶段二：定义业务界限上下文阶段三：分析业务界限上下文之间的依赖关系阶段四：基于子域进行领域建模分析，构建聚合并形成服务阶段五： 设计微服务和微服务分层架构DDD分为战略设计和战术设计两个部分，今天我就介绍一下战术设计这个部分。 战术设计就是将战略设计阶段产生的输出进行微服务架构落地的过程。以下是基于DDD的微服务架构构建旅程，分为五个主要的阶段：识别业务领域和子域及其类型 定义业务界限上下文 分析业务界限上下文之间的依赖关系 .