DDD.实践思考随笔

目录

微服务为什么用DDD

领域

限界上下文

实体和值对象

聚合和聚合根

​​​​​​​领域事件

​​​​​​​分层架构

​​​​​​​架构模型

​​​​​​​中台:数字转型后到底应该共享什么


​​​​​​​微服务为什么用DDD

微服务最大的问题是拆分问题,会导致过度拆分而无法上线。而DDD 核心思想是通过领域驱动设计方法定义领域模型,从而确定业务和应用边界,保证业务模型与代码模型的一致性。

DDD 是一种处理高度复杂领域的设计思想,它试图分离技术实现的复杂性,并围绕业务概念构建领域模型来控制业务的复杂性,以解决软件难以理解,难以演进的问题。DDD 不是架构,而是一种架构设计方法论,它通过边界划分将复杂业务领域简单化,帮我们设计出清晰的领域和应用边界,可以很容易地实现架构演进。

微服务有服务识别,服务制约,服务管理。 DDD解决的是微服务的识别和制约,即边界划分。 

微服务更关注技术落地,DDD更关注怎么做模型抽象。

淘宝原来是单体应用,访问量上去了,开始大型机,商用WEB SERVER和ORACEL,但成本太高,只好拆分利用免费的MySql,Tomcat,小型机。公司发展,淘宝,天猫等不同部门对部分模块进行了重复实现,比如,文件管理服务,消息中心服务等。同时也产生了信息孤岛,各部门数量不能融合。因此提出中台,将公司所有数量,功能聚合。相当于原来一个公司每个部门都有研发部,现在简历了一个研发中心。而中台需要对整个公司服务,单体应用肯定扛不住,还得用微服务架构风格,那公司业务那么多那么复杂,把那些业务逻辑放下一个模块服务实现呢?指导思想就是DDD,一个业务领域的业务放在一块,用一个或者多个微服务实现。 怎么实现,战术层面,DDD确定了跟微服务技术架构的映射,指导你怎么编代码。

DDD识别服务,微服务是架构风格,微服务技术栈中有个叫SpringClound来落地,实现微服务是为了应对高并发高可用,和微服务同时出镜的是敏捷,敏捷是一种思想,需求不确定,那就不要一次输入,飞多个迭代做,中间还能有调整的机会。团队怎么进行敏捷开发呢?Scrum!当然敏捷还有其他的实践方法论。

怎么上手DDD,杀猪杀屁股一人一个刀口。激进派做法,不管理解不理解思想,直接把DDD那套代码结构搬过来再说,好处是上手快,缺点是只知其然不知其所以然,貌合神离。由上述可以看出,会微服务技术栈+较好的抽象能力,也可以解决服务识别和制约问题,也可以说,用了DDD战略层面内容,当然抽象哪都需要,说是DDD的内容有点不要脸了。个人暂时观点,从业务领域抽象为指导思想,落地微服务,然后在逐渐借鉴DDD战术层面的技巧,不要为了DDD而DDD。 保守派的做法!  

​​​​​​​领域

领域、子域、核心域、通用域和支撑域

DFD对应面相过程的单体应用设计,用例图对应面向对象设计,DDD是面相SOA的设计方法论。思想都是: 自顶向下逐层分解,分治思想。领域就是模块,子域就是子模块。核心域就是核心模块,通用域也是几个模块通用的模块,支撑域是对几个模块有支撑作用的,通用和支撑的区分是通过判断,一个模块是否被另一个模块依赖,如果子模块被上层看不到则是支撑,如文件存取,数量读取。如果一个模块只是所有模块的共用才进行的独立,在上一层是看得到这个模块的,那么就是通用,比如认证鉴权。不同的业务场景划分分类也不同,不同类型的域对待的策略不同,在资源紧张时有效保证核心域的开发。

是不是感觉这些东东不说出来你也懂?这就是为什么DDD在03年提出,现在火的原因,单体应用时大家都这么做,只不过不这么说,多学些概念没啥用,可复杂业务的微服务分格架构 或者 复杂的单体转分布式服务架构 就遇到了领域重新识别和管理的难题,DDD能较好的解决。 所以说DDD也是有他的适用范畴滴

限界上下文

通用语言和上下问边界

一个东西在不同的领域内叫法可能不同,所以需要统一术语,当然得说你边界,什么范围内叫租户什么范围内叫机构。术语的语意背景就是上下文,这个范围边界就是上下文的边界。通常一个上下文就可以对应一个领域或者子领域,实现时就对应一个微服务。

对应面相服务的服务识别和制约,制约即是定义边界,这就对应上了。

​​​​​​​实体和值对象

实体,是一种具有生命意义的对象,他有属性,操作,有唯一ID,比如订单,员工,货物等等。 在设计的时候可以是一个小模块/领域,实现的时候可以是一个类或者一个包,一个微服务。 区别于在设计阶段就开始做ER建模不同,DDD更重视实体识别和设计,而后才是对实体的持久化,当然这样更容易违反关系数据表的设计范式,选择是没关系,能用就行。

值对象,是一种特殊的实体,他没有生命周期,没有唯一ID,只能做实体一个属性,不错的时候可以是外键,如果不做查询,可以序列化一个JSON字符串存储,更新时整体替换。

​​​​​​​聚合和聚合根

聚合是最小的业务单元,业务是由内部的多个实体组合完成,聚合根是聚合的管理者,对外接口和聚合内实体的持久化操作。
聚合是逻辑抽象概念,一个微服务可以包含多个聚合。聚合之间尽可能不要join数量,而是使用调用完成数据的聚合。

聚合内数量使用强一致性,聚合外保证最终一致性

尽可能使用小聚合,方便业务的重组和扩展

聚合怎么抽象,从实体然后分组,或者从顶向下逐渐分解。 这都是对现有业务的分析,对增量模型怎么做是个挑战

​​​​​​​领域事件

领域内强一致性,领域外最终一致性。一个微服务包含一个或多个领域模型,一个事物保证一个领域的持久化。

领域事件就是解决领域外最终一致性机制。可以解决实时调用的压力,也可保证领域的完整性。

​​​​​​​分层架构

分层架构以及演进

三层架构和DDD分层架构的映射

使用分层架构对微服务进行演进

​​​​​​​架构模型

DDD分层架构,整洁架构,六边型架构都是聚焦领域,以分层实现领域和应用的逻辑分离,资源和逻辑代码的分离。

不同点是,整洁架构更关注依赖关系,六边形架构更关注服务对外的形态是用不同端口提供服务,分层则更注重分层。

聚焦领域,一个公司的业务不大变化,领域相对稳定。需求不确定可以通过前端变化和应用层业务的重新编排实现。 这个相对稳定的模块,就称为中台。中台分为项目级和企业级,项目级中台,可以通过一个微服务来做业务的编排和服务的调用,而企业级就需要单独独立出来一层,来做编排和对外层需求的适配。

​​​​​​​中台:数字转型后到底应该共享什么

中台源于平台,平台只是从功能的角度来复用,中台则从企业战略的高度,抽象出公司的核心业务能力建设的平台,具体业务则由前台来编排。中台分为业务中台和数据中台,数据中台可以用数量仓库,大数据技术进行采集,分析和融合,主要的作用是为了打通微服务导致的数量孤岛,为业务中台,前台做数量支撑,同时分析出的数量反推业务的发展和创新。 DDD强调的是建立高内聚的领域,符合建设中台思路。

如何用DDD重构中台业务模型

DDD指导企业信息系统数字化转型有两种策略,从上到下,从下到上,这是具体方法,对应信息化理论就是,推到重来,迭代演化。实际情况是一个公司刚开始业务领域不明确,也没资源去建立一个大中台,所以更多的是演化。演化的核心就是保证现有业务为前提,提炼和沉淀通用领域,重建核心业务领域,逐渐替代和支持分散在各个部门的核心业务系统。 刚学习软件时听老范说,做系统时就是先把系统涉及到的单子,名词全部罗列收集,然后归类,这个过程就看抽象能力了。其实DDD就是归类的具体方法论,内力还是抽象能力,那些单据名词就是聚合或者属性,归类就是划分领域,类型的边界就是这叫限界上下文,每一个聚合有个管理员就是聚合根,单据就是实体,属性或者一些字典数量存储就是值对象。有了思想代码自然现成,只不过很多人想的是直接告诉我怎么做,不想去思考罢了!根子原因是,企业会为会怎么做买单,不会为会为什么买单,浮躁之风无处不在。

边界:微服务的各种边界在架构演进中的作用?

逻辑,代码,物理 三种边界
逻辑边界是指业务抽象的边界,对应聚合的边界,多个聚合形成的微服务间的业务边界
代码边界是从代码纬度来区分不同聚合,微服务的隔离边界,也就是代码目录
物理边界强调物理隔离,即进城隔离,微服务就是进程隔离,通信,调用依赖关系
严格要求的边界是为了隔离,隔离是为了重组代价更小,微服务的重点是更容易迭代,无论是扩容,局部重构,重组聚合

你可能感兴趣的:(项目管理,java,微服务,DDD)