温州网站建设方案表,平面设计公司企业logo设计,建网站找我,电子商务系统网站建设大白话DDD#xff08;DDD黑话终结者#xff09;
一、吐槽的话
相信听过DDD的人有很大一部分都不知道这玩意具体是干嘛的#xff0c;甚至觉得它有那么一些虚无缥缈。原因之一是但凡讲DDD的#xff0c;都是一堆特别高大上的概念#xff0c;然后冠之以一堆让人看不懂的解释…大白话DDDDDD黑话终结者
一、吐槽的话
相信听过DDD的人有很大一部分都不知道这玩意具体是干嘛的甚至觉得它有那么一些虚无缥缈。原因之一是但凡讲DDD的都是一堆特别高大上的概念然后冠之以一堆让人看不懂的解释。作者曾经在极客时间上买了本DDD实战的电子书被那些概念一路从头灌到尾灌得作者头昏脑涨一本电子书那么多文章愣是没有一点点像样的案例看到最后也 没明白那本电子书的作者究竟想写啥。原因之二是DDD经常出现在互联网黑话中如果不能稍微了解一下DDD中的名词我们一般的程序员甚至都不配和那些说这些黑话的人一起共事。
为了帮助大家更好的理解这种虚无缥缈的概念也为了更好的减少大家在新词频出的IT行业工作的痛苦作者尝试用人话来解释下DDD并且最后会举DDD在不同层面上使用的例子来帮助大家彻底理解这个所谓的“高大上”的概念。
二、核心概念
核心的概念还是必须列的否则你都不知道DDD的名词有多么恶心但我会用让你能听懂的话来解释。
1、领域/子域/核心域/支撑域/通用域
领域
DDD中最重要的一个概念也是黑话中说的最多的领域指的是特定的业务问题领域是专门用来确定业务的边界。
子域
有时候一个业务领域可能比较复杂因此会被分为多个子域子域分为了如下几种:
核心子域业务成功的核心竞争力。用人话来说就是领域中最重要的子域如果没有它其他的都不成立比如用户服务这个领域中的用户子域通用子域不是核心但被整个业务系统所使用。在领域这个层面中这里指的是通用能力比如通用工具通用的数据字典、枚举这类感叹DDD简直恨不得无孔不入。在整个业务系统这个更高层面上也会有通用域的存在指的通用的服务用户服务、权限服务这类公共服务可以作为通用域。支撑子域不是核心不被整个系统使用完成业务的必要能力。
2、通用语言/限界上下文
通用语言
指的是一个领域内同一个名词必须是同一个意思即统一交流的术语。比如我们在搞用户中心的时候用户统一指的就是系统用户而不能用其他名词来表达目的是提高沟通的效率以及增加设计的可读性
限界上下文
限界上下文指的是领域的边界通常来说在比较高的业务层面上一个限界上下文之内即一个领域。这里用一张不太好看的图来解释 3、事件风暴/头脑风暴/领域事件
事件风暴
指的是领域内的业务事件比如用户中心中新增用户授权用户修改密码等业务事件。
头脑风暴
用最俗的人话解释就是一堆人坐在一个小会议室中开会去梳理业务系统都有哪些业务事件。
领域事件
领域内子域和子域之间交互的事件如用户服务中用户和角色交互是为用户分配角色或者是为角色批量绑定用户这里的领域事件有两个一个是“为用户分配角色”,另一个是“为角色批量绑定用户”。
4、实体/值对象
实体
这里可以理解为有着唯一标识符的东西比如用户实体。
值对象
实体的具体化比如用户实体中的张三和李四。
实体和值对象可以简单的理解成java中类和对象只不过这里通常需要对应数据实体。
5、聚合/聚合根
聚合
实体和实体之间需要共同协作来让业务运转比如我们的授权就是给用户分配一个角色这里涉及到了用户和角色两个实体这个聚合即是用户和角色的关系。
聚合根
聚合根是聚合的管理者即一个聚合中必定是有个聚合根的通常它也是对外的接口。比如说在给用户分配角色这个事件中涉及两个实体分别是用户和角色这时候用户就是聚合根。而当这个业务变成给角色批量绑定用户的时候聚合根就变成了角色。即使没有这样一个名词我们也会有这样一个标准让业务按照既定规则来运行举个上文中的例子给用户A绑定角色1用户为聚合根这样往后去查看用户拥有的角色也是以用户的唯一标识来查即访问聚合必须通过聚合根来访问这个也就是聚合根的作用。
三、用途及案例
目前DDD的应用主要是在战略阶段和战术阶段这两个名词也是非常的不讲人话所谓的战略阶段其实就是前期去规划业务如何拆分服务服务之间如何交互。战术阶段就是工程上的应用用工程化做的比较好的java语言举例子就是把传统的三层架构变成了四层架构甚至是N层架构而已。
1、微服务的服务领域划分
这是对于DDD在战略阶段做的事情假如目前我司有个客服系统内部的客服人员使用这个系统对外上亿的用户提供了形形色色的服务同时内部人员觉得我们的客服系统也非常好用老板觉得我们的系统做的非常好可以拿出去对外售卖以提高公司的利润那么这时候问题就来了客服系统需要怎样去改造才能够支持对外售卖呢经过激烈的讨论大致需求如下
对外售卖的形式有两种分别是SaaS模式和私有化部署的模式。SaaS模式需要新开发较为复杂的基础设施来支持比如租户管理用户管理基于用户购买的权限系统能够根据购买情况来给予不同租户不同的权限。而私有化的时候由于客户是打包购买这时候权限系统就不需要再根据用户购买来判断。数据同步能力很多公司原本已经有一套员工管理系统通常是HR系统或者是ERP这时候客服系统也有一套员工管理需要把公司人员一个一个录入进去非常麻烦因此需要和公司原有的数据来进行同步。老板的野心还比较大希望造出来的这套基础设施可以为公司其他业务系统赋能能支持其他业务系统对外售卖
在经过比较细致的梳理DDD管这个叫事件风暴/头脑风暴之后我们整理出了主要的业务事件大致如下
1、用户可以自行注册租户也可以由运营在后台为用户开通租户每个租户内默认有一个超级管理员租户开通之后默认有系统一个月的试用期试用期超级管理员即可在管理端进行用户管理添加子用户分配一些基本权限同时子用户可以使用系统的一些基本功能。
2、高级的功能比如客服中的机器人功能是属于要花钱买的试用期不具备此权限用户必须出钱购买。每次购买之后会生成购买订单订单对应的商品即为高级功能包。
3、权限系统需要能够根据租户购买的功能以及用户拥有的角色来鉴权如果是私有化由于客户此时购买的是完整系统所以此时权限系统仅仅根据用户角色来鉴权即可。
4、基础设施还需要对其他业务系统赋能。
根据上面的业务流程我们梳理出了下图中的实体 最后再根据实体和实体之间的交互划分出了用户中心服务以及计费服务这两个服务是两个通用能力服务然后又划分出了基于通用服务的业务层分别是租户管理端和运营后台以及提供给业务接入的应用中心架构图如下 基础设施层即为我们要做的东西为业务应用层提供通用的用户权限能力、以及售卖的能力同时构建开发者中心、租户控制台以及运营后台三个基础设施应用。
2、工程层面
这个是对于DDD在战术设计阶段的运用以java项目来举例子现在的搞微服务的都是把工程分为了主要的三层即控制层-逻辑层-数据层但是到了DDD这里则是多了一层变成了控制层-逻辑层-领域能力层-数据层。这里一层一层来解释下
四、总结
在解释完了各种概念以及举例子之后我们对DDD是什么有了个大概的认知相信也是有非常多的争议。作者搞微服务已经搞了多年也曾经在梳理业务的时候被DDD的各种黑话毒打过也使用过DDD搞过工程。经历了这么多这方面的实践之后觉得DDD最大的价值其实还是在梳理业务的时候划分清楚业务领域的边界其核心思想其实还是高内聚低耦合而已。至于工程方面现在微服务的粒度已经足够细完全没必要再多这么一层。这多出来的这一层多少有种没事找事的感觉。更可笑的是这个概念本身在对外普及自己的东西的时候玩足了文字游戏让大家学的一头雾水。真正好的东西是能够解决问题并且能够很容易的让人学明白而不是一昧的造新词去迷惑人也希望以后互联网行业多一些实干少说一些黑话。
