领域模型是领域中概念类或现实世界中对象的视觉表示。领域模型也称为概念模型、领域对象模型和分析对象模型。——我们在日常开发中，经常会为了一些功能点争论不休，“这个功能不应该我改，应该由你来改”。经过妥协和更改，我们仍然不明白为什么要在我们这边更改此功能。边变。与传统的架构设计不同，领域驱动设计（DDD）可能会帮你在这个时候实现清晰的划分。什么是DDD领域驱动设计，最初由EricEvans提出，但多年来一直停留在概念阶段。真正能够变现落地的项目和公司寥寥无几。事实上，阿里巴巴内部正在大力推广DDD的理念。主要可以帮助我们解决传统单体中心化架构难以快速响应业务需求落地的问题，为中端和微服务盛行的场景提供指导。DDD给我们提供的是架构设计的方法论，既面向技术，又面向业务，从业务的角度去把握设计方案。DDD的作用是统一思维：统一项目中涉及的业务、产品、开发各方对问题的认知，而不是开发和产品的统一，业务和产品的统一，造成差异.分工明确：需要明确定义领域模型来解决方方面面的问题，团队对这些问题形成分钟的理解。反映变化：需求在不断变化，所以我们的模型也在不断变化。领域模型可以真实地反映这些变化。边界分离：领域模型与数据模型分离，领域模型用于定义哪些需求在何处实现，并保持结构清晰。DDD的概念实体有一个带有唯一标志的核心领域对象，这个标志在整个软件生命周期中都不会改变。这个概念类似于我们常用的与数据库打交道的软件模型中的Model实例。唯一不同的是DDD中的这些实体会包含与实体相关的业务逻辑，实体是操作行为的载体。值对象附加到实体并由对象属性标识。它将一些相关的实体属性打包在一起，形成一个新的对象。举个例子：比如一个用户实体包括用户名、密码、年龄、地址，地址包括省、市、省等属性，这些属性被封装成一个属性集，就是一个值对象。聚合的实体和价值对象代表了个人的能力，我们的业务逻辑往往非常复杂，不能靠个人来完成。这时候需要多个实体和值对象协同工作，这种协同组织就是聚合。聚合是数据修改和持久化的基本单位。同一个聚合内必须保证事务的一致性，所以在设计的时候需要保证聚合的设计拆分到最小，以保证效率和性能。聚合根也称为根实体，是聚合的管理者，代表聚合入口的特殊实体。抓住聚合根可以捕获整个聚合。领域服务在某些领域的操作是动词，不能简单归类为实体或值对象。这样的行为被领域识别出来后，应该声明为服务，其作用只是为领域提供相应的功能。域事件由特定域中的用户操作触发，表示过去发生的事件。比如充值成功、充值失败等事件。失血模型四种模式中只有简单的getset方法，是对一个实体最简单的封装，其他业务行为全部由服务类完成。@Data@ToStringpublicclassUser{privateLongid;privateStringusername;privateStringpassword;privateIntegerstatus;privateDatecreatedAt;privateDateupdatedAt;privateIntegerisDeleted;}publicclassUserService{publicbooleanisActive(Useruser){returnuser.getStatus().equals(StatusEnum.ACTIVE.getCode()中的贫血模型});业务领域行为在模型的基础上聚合，领域对象的状态变化停留在内存层面，不关心数据持久化。@Data@ToStringpublicclassUser{privateLongid;privateStringusername;privateStringpassword;privateIntegerstatus;privateDatecreatedAt;privateDateupdatedAt;privateIntegerisDeleted;publicbooleanisActive(Useruser){returnuser.();}}拥塞模型基于贫血模型，负责数据持久化。@Data@ToStringpublicclassUser{privateLongid;privateStringusername;privateStringpassword;privateIntegerstatus;privateDatecreatedAt;privateDateupdatedAt;privateIntegerisDeleted;privateUserRepositoryuserRepository;publicbooleanisActive(Useruser){returnuser..username=username.trim();userRepository.update(user);}}不需要充气血模服务，所有业务逻辑和数据存储都放在一个类中。对于DDD来说，失血和血肿都是不合适的。失血太轻，没有聚集。血肿只适合初学者这样写代码。那么充血模型和贫血模型如何选择呢？充血模型依赖repository接口，与数据存储密切相关，存在破坏程序稳定性的风险。建模方法用例分析法用例分析法是最简单、最可行的领域建模方法。大致可以分为几个步骤：获取用例、收集实体、添加关联、添加属性、模型细化。获取用例：提取领域规则描述收集实体：定位实体，添加关联：用动词链接两个实体添加属性：获取实体属性模型细化：可选步骤，模型可以用UML概括和组合表示四色建模方法起源于《Java Modeling In Color With UML》，是一种模型分析和设计方法。通过将所有模型分为四种类型，有助于模型清晰可追溯。简单来说，四种颜色专注于某人在一个地方的角色，用某物的角色做某事。事件风暴法事件风暴法类似于头脑风暴法。简单地说，就是谁做了什么，发生了什么，基于什么时间发生了什么。架构分层不同于左图传统架构的分层，一般的DDD分层会有一些变化。Application：包含事件注册、业务逻辑等Domain：聚合、实体、值对象InfraStructure：基础设施封装、数据库访问等总结DDD是一个完整的方法论，可以帮助我们合理设计系统架构。同时，好的模板应该是不断适应变化的，DDD也可以帮助我们更快捷方便的支持业务发展。本文转载自微信?“科技喵喵”，可通过以下二维码关注。转载本文，请联系科技喵喵?。
