作者回复: 后面章节会有一章专门讲,会有一个案例。跟头脑风暴类似,通过它设计领域模型。
编辑回复: 忠实老粉了啊~期待你的打卡!
作者回复: 选了一个企业级的中台设计,从领域建模到微服务设计选取了几个典型的中台,过程基本是完整的。最后的示例,源代码只到服务和实体类级别,里面具体业务实现代码没有。也就是说微服务整体架构的框架搭起来,但没有往里填肉。
作者回复: 斯图尔特,你好。
领域模型里面都是一些领域对象,这些领域对象是构成系统的一些业务行为。你说的这些角色不知道是不是指系统建设过程中的角色。其实DDD并不改变原来软件开发过程中的角色,只是工作模式发生了变化,大家一起设计领域模型,设计微服务。领域专家是熟悉并深刻理解这个领域的人,可能是业务人员,也可能会是产品经理,甚至可能是开发人员。传统企业一般有信息和业务一说。业务人员一般是指业务部门的人员。
作者回复: DDD包括战略设计和战术设计,战略设计主要面向业务完成领域建模,战术设计是根据领域模型完成微服务设计的过程。领域的概念应该包括您所说的代码部署系统或者配置管理系统,只要能在这些领域中能够提炼出领域模型就可以。
作者回复: 第一个问题,我想知道不同工厂软件需求的差异主要在什么地方?如果差异在流程和服务编排,DDD的分层架构应用服务很合适。如果领域层业务逻辑差异不大的话,就比较好解决。个人感觉领域层的核心逻辑差异应该不会大。
第二个问题,DDD数据库方面采用依赖倒置的方式,实现业务逻辑的时候,不会有数据库方面的逻辑,都是领域对象的行为,数据库相关代码在仓储实现中实现。也就是说业务实现与数据库是松耦合的,换数据库的时候,只需要换仓储逻辑就可以了,不会影响核心业务逻辑。
第三方问题,你说的这几个子域相对清晰,直接在子域做事件风暴,建立领域模型,设计微服务就可以了。
第四个问题,见以上三条。总之,保持领域层领域模型的稳定,用应用层去适配外部需求的变化,用户接口层面向不同渠道提供个性数据服务。
作者回复: 传统SOA架构基本是单体模式,也就是集中式架构。因为需求会越来越多,系统会越来越庞大。系统大了后就不太方便放到容器之类的环境上,只能用weblogic之类的中间件,靠手工来运维了。
作者回复: 边界清晰了,以后微服务的演进就相对简单。一般来说聚合内部的功能都是核心的领域逻辑,是一些相对原子化的业务功能,受外部影响比较小。所以在微服务演进时可以以聚合为单元来进行微服务重组。
作者回复: 很快就到了,耐心等待哈。
作者回复: 你说的这几个问题我后面都会讲到,耐心等待哈。
第一个问题:会通过事件风暴来建立领域模型。
第二个问题:前后端分离后,可通过API网关调用后端微服务,或者对于复杂的业务场景可以考虑在前端与后端微服务之间增加一个BFF的微服务,可以对多个微服务进行服务组合和编排。
第三个问题:限界上下文边界理论上就是微服务的边界。
作者回复: 一起学习和进步哈。
作者回复: 专栏里面会有详细的过程介绍,先理解概念,然后学会怎么用事件风暴建立领域模型,根据领域模型来设计微服务。等着后面的实战篇哈。
作者回复: 很多的时候领域的细分会根据业务流程阶段或者模块功能,这两个方面业务有很好的内聚性,很可能就对应到了子域。如果领域实在太大,你可以考虑将它分成小的领域,然后在这小的领域中去做事件风暴,划分限界上下文,并确定哪些聚合放在哪个限界上下文里,这里领域专家会起到比较大的作用。不过建立领域模型后,你还需要看看其它子域是否有重叠的内容,如果有的话,还需要对领域模型重组。
作者回复: 您说的这些问题确实很常见,很多企业都是业务的归业务,技术的归技术。DDD其实也跟中台建设一样,也是一种企业和组织文化的变化,需要业务和技术融合在一起。
作者回复: 希望能对你有帮助。
编辑回复: 姗姗来迟~莫怪莫怪!
作者回复: 正好可以用上^_^。
作者回复: DDD名词是很多,前后稍微多看几遍吧。
作者回复: 每个企业都不太一样的,跟商业模式和战略定位有关。个人感觉在电商领域,订单和商品是比较通用的业务能力,偏通用会多一些。