万网云虚拟主机上传网站,芜湖新芜湖网站建设,开发一个网站要学什么软件,沽源网站建设1 前言
本文与大家一起学习并介绍领域驱动设计(Domain Drive Design) 简称DDD#xff0c;以及为什么我们需要领域驱动设计#xff0c;它有哪些优缺点#xff0c;尽量用一些通俗易懂文字来描述讲解领域驱动设计#xff0c;本篇并不会从深层大论述讲解落地实现#xff0c;这…1 前言
本文与大家一起学习并介绍领域驱动设计(Domain Drive Design) 简称DDD以及为什么我们需要领域驱动设计它有哪些优缺点尽量用一些通俗易懂文字来描述讲解领域驱动设计本篇并不会从深层大论述讲解落地实现这些大家可以在了解入门后再去深层次学习探讨或在后续进阶和高级篇了解希望通过本文介绍可以让大家快速了解DDD并有一个基础的认知DDD本身就是理论的集合很难在不积累理论情况下来有效的实施DDD仅仅看一些代码案例后就开搞,最终出来东西也是东施效颦莫要好高骛远。 最后期望大家在工作中能多思考如你所负责项目如果用DDD如何设计、以及会面临哪些挑战。
学习了解DDD之前期望大家可在温顾下以往我们所了解掌握一些知识努力让自己所学所掌握的内容沉淀下来推荐阅读系列。
Head First 设计模式:基础面向对象概念和重要的设计模式UML面向对象建模基础:从需求到分析从分析到设计从设计到编码UML都有用武之地实现领域驱动设计很厚更加务实推荐阅读领域驱动设计张逸-DDD开山之作挺玄幻的多读几遍受益匪浅
2 定义与概念
领域驱动设计(DDD)提出是从系统的分析到软件建模的一套方法论。将业务概念和业务规则转换成软件系统中的概念和规则从而降低或隐藏业务复杂性使系统具有更好的扩展性以应对复杂多变的现实业务问题。总结它是一套完整而系统的设计方法、是一种设计思维、一种方法论并不是系统架构一种架构设计原则、思维。
2.1、为什么要使用领域驱动设计,或者说其用途,应用场景式什么? 善于处理高复杂业务的产品研发、可帮助我们提炼稳定的产品内核(领域模型中称为核心域); 通过建模可提高建模高内聚、降低模型间的耦合度提高系统的可扩展性与稳定性; 强调团队与领域专家的合作沟通有助于建立一个沟通良好的团队组织 统一设计思想与设计规范有助于提高团队成员的架构设计能力和面向对象设计能力; 现有的微服务建构都是遵循领域驱动设计的架构原则; 如果你负责的软件系统并不复杂那么你确实不需要学习领域驱动设计!
2.2、领域驱动设计跟时下流行的架构思维最大的区别是什么
领域驱动设计的思维是对象行为服务所有的设计围围绕着对象、行为、服务展开
时下流行架构设计思维是基于MVC分层架构进行纵向扩展分业务模块进行产品横向扩展; 2.2.1. 传统的方案
三层应用架构数据-应用(业务逻辑层)-展现通常是以数据位为起点进行数据库分析设计。 服务层过重数据模型失血没东西 面条式编程或者面向数据库编程服务层围绕数据库作业完成业务逻辑经常一条线撸到底
3) 代码一整块一整块的过重很难扩展复用
数据库模型只是数据库映射没有相关的行为支撑行为都被上一层Service给完成等了因此是失血 的领域模型
2.2.2. 领域驱动方案
架构四层在DDD分层结构中将三层中业务逻辑拆解为应用层和领域层核心业务逻辑表现下沉到领域层去实现以业务领域模型为核心建模(面向对象建模)更能体现对现实世界的抽象其优点如下
1) 轻服务层充血的领域模型 领域模型封装和实现各自应有的行为可以认为是一个高内聚、低耦合的组件 由于模型集数据与行为于一身是一种自解释的对象代码复用性高业务逻辑清晰明确;
用户界面层主要职责是通过用户界面向用户显示数据信息同时解释用户的命令并把用户的请求发送到应用层。应用层通过调用基础设置和领域层完成数据资源操作及业务流程编排相当于BS层领域层将业务逻辑高度内聚到领域层所以领域层是整个系统的核心它只与实际业务相关不关心任何技术细节尽可能做到与持久化无关基础设施层包含了任何类型的框架、数据库访问代码或者公共的方法等纯技术的一层 2.3、如何学习领域驱动设计
没有谁能够做到领域驱动设计的一蹴而就所谓理论联系实际在刚开始接触或学习设计领域驱动时总会有一种诉求希望能给出公式般的设计准则或规范似乎软件设计就像拼积木一般只要遵循图示给出的拼搭过程不经思考就能拼出期待的模型这似乎不切实际的幻想要掌握领域驱动设计首先要了解掌握一些概念以知识理论在此基础之上思考这些概念背后蕴含的原理设计原则思考限界上下文(Bounded Context)边界的划分实际还是围绕高内聚、低耦合原则的体现只是我们考虑什么内容才是高内聚如何抽象才能做到低耦合在分层架构中各层之间该如何协作出现了依赖如何解耦仍然需要从重用与变化的角度去思考设计决策。
3 领域驱动设计
领域驱动设计强调以领域为核心驱动力通过模型驱动设计来保障领域模型与程序设计的一致,领域模型不应该包含任何技术实现因素模型中的对象真实的表达了领域概念却不受技术实现的约束领域模型本身和技术无关领域驱动从设计上划分为战略设计和战术设计。
一个领域是由一个或多个模型组成从定义上讲模型是领域的抽象从理解上将模型可以认为是一个高内聚、低耦合的组件、模块也可以称为一个子领域;模型重在建模过程建模过程会抽象出一系列领域对象和领域服务在DDD中定义一系列的标准领域元素用于领域建模如战术设计元模型 3.1. 战略设计
强调业务战略上的重点如何按重要性分配工作以及如何进行最佳遵循量大原则 必须指导设计决策以便减少各个部分之间的相互依赖在使用设计意图更为清晰的同时而又不失去关键的互操作性和系统性 必须把模型的重点放在捕获系统概念核心也就是系统的远景上。
3.1.1 子域划分
整个业务领域的一部分关注与宏观业务通过对大领域进行划小在业务间划分出概念上分界线便于在系统筹划阶段决策如何分配资源(人、钱)。
1) 核心子域领域中最有价值和最核心的部分产品成败的关键核心竞争力,在DDD开发中主要关注核 心域给予最高优先级; 支撑子域项目中对核心子域起着支撑作用的相关功能专注于业务的某个反面; 通用子域与项目意图无关的内聚子领域解决一些通用问题任何专有的业务都不应该放在通用子域;
3.1.2. 战略建模
关注点在于系统物理划分根据你对领域的分割结果及公司或部门的组织结构决策如何划分子系统比如分出几个系统间如何交互该层面往往暂不会涉及够多技术细节。
1) 限界上下文(Bounded Context):通俗讲指系统中模块微服务架构中的子服务、单体中包(Java)或名称空间(C#)对系统的一个物理划分限定了领域模型的边界在更深层次介绍深挖这东西得分成两个词限界、上下文可以理解成系统设计之初你需要画一个圈设置一个范围保证领域模型限制在这个圈内不可串场这个‘圈’即为限界上下文。 通用语言:用于统一领域专家、产品、研发、测试大家在使用的语言避免出现需求理解不一致设计与需求不一致沟通不顺畅等问题简单来说大家在一起聊某个东西的时候都能明白彼此所致的是什么场景不同同一个词就会有着不同含义。 上下文映射图用图的方式表达出限界上下文之间关联,后续会单独在详细介绍上下文映射图如 合作关系、防腐层、大泥球等
3.2. 战术设计
依赖于领域模型和通用预言通过技术模式将领域模型和通用预言中的概念映射到代码实现中。随着模型的进化代码实现也会进行重构以更好的体现模型概念。
主要包括 代表领域中的概念如实体、值对象、领域服务、模块等 用于管理对象的生命周期。如聚合、工厂、仓库等; 用于集成或跟踪如领域事件等; 3.3. 名词解释 领域/子域什么领域从广义上将领域即是一个组织所做的事情以及所包含的一切领域可大可小有界限不是无限大如电商领域交易领域购物领域等比如我们常听客户说“我们有这样几块业务”一般来说这里所谓几块儿就是指子域 。 实体(entity)这个词被我们广泛使用甚至过分使用实体是一个重要的概念一个典型实体应具备3个要素(身份标识、属性、领域行为)必须有唯一的身份标识没有身份标识的领域对象就不是实体。如User对象就是一个实体。 属性实体的属性用来说明主体的静态特征并持有数据与状态。
Data
public class Product{private String sku;private String name;private Price price;
}
领域行为实体拥有领域行为可以更好地说明其作为主体的动态特征。一个不具备动态特征的对象不属于领域行为。
Data
public class Product{private String sku;private String name;private Price price;//变更状态的领域行为public void changePriceTo(Price newPrice){//设计产品新加个.......}
}
值对象(value object)比较抽象通常作为实体的属性区分值对象与实体的区别在于值对象是不可变的并且没有唯一标识仅由其属性的值定义参与则对它的判断是依据值还是依据身份标识前者是值对象后者是实体
举个小例子订单项和订单的关系多对一一个订单里有多条订单项一个订单项只会出现在一个订单里组合关系部分不能脱离主体单独存在
public class Order {int id;User user;
}public class OrderItem {private int id;private Product product;private int num;private Order order;
} 6) 聚合根聚合中需要指定一个实体作为聚合根来作为整个聚合的对外触电也就是说外部只能通过聚合根实现对内部对象的访问这样的限制可以对内部对象实现最大化的保护。
4 价值是什么
几乎所有项目的发展都有这样一个规律初期需求简单中后期业务激增系统复杂度升级导致最初的设计理念需要大刀阔斧的改革所以系统越复杂、代码规模越大DDD 的优势就越明显。
合作沟通强调团队与领域专家的合作沟通有助于建立一个沟通良好的团队组织统一思想统一设计思想与设计规范有助于提高团队成员的架构设计能力和面向对象设计能力系统灵活通过建模可提高模型的高内聚降低模型建的耦合度提高系统的可扩展性与稳定性产品内核善于处理高复杂度业务产品研发可帮助我们提炼稳定的产品内核业务沉淀领域模型是系统的核心是领域内业务的直接沉淀具有非常大的业务价值。 5 基础篇结束语
微服务划分的一个重要理论基础就是领域驱动设计但由于DDD门槛高、概念多体系庞大又抽象再加上实践经验和案例缺少很多开发人员对DDD存在不少疑惑或只停留在平时依靠检索或身边同事谈及耳闻了解DDD通过本篇初步认识了领域驱动设计、前期我们先暂短介绍这里后续会将从代码层面入手分享DDD实现落地。 作者京东物流 边雷 来源京东云开发者社区 自猿其说Tech 转载请注明来源
