名词科普
集群、分布式、SOA、微服务
单体:一个应用里包含完整的服务
集群:不同服务器部署同一套应用对外提供服务,指同一组件的多个实例,是一种物理形态。
分布式:与集群不同,强调的是不同的模块部署在不同服务器上,提供完整的服务(可以存在相同服务部署在多个节点上),强调的是工作方式
SOA(Service-Oriented Architecture):面向服务的架构,是一种设计方法。服务拆分,多个服务相互依赖通过接口和协议联系起来
中心化实现:ESB(Enterprise Service Bus ) 企业服务总线,各服务通过ESB交互的方式实现与其他服务的通信,解决异构系统的连通性,屏蔽其他服务的细节。
去中心化:微服务,SOA的升华
微服务:强调业务的彻底组件化和服务化,每个服务可单独开发,迭代运行,更符合单一职责原则,通过网关
服务发现与注册,restful api风格轻量级通信等等,各司其职
系统老化谁的锅

DDD是什么
DDD最早由Eric Evans提出一种的软件设计理念,通过一些规则和概念来指导如何合理的进行领域划,防止程序腐化,帮助整个研发团队内部更好的进行沟通。
DDD的一些概念
领域(Domain):指软件要解决的业务问题和诉求,是一个广义的概念,包括业务的各种概念、规则和逻辑。
领域模型(Model):业务概念在程序中的一种表达方式,使用面向对象的编程语言中的类作为业务概念的承载体,也可以使用 UML 可视化地表达模型。
通用语言(Ubiquitous language):指在软件设计中,业务人员和开发人员需要使用无歧义的统一语言来对话,包括对概念的统一理解和定义,以及业务人员参与到软件建模中。
实体(Entity):领域模型中面向对象语言的具体体现,一般是一个类,具有唯一标识符,且标识符在经历过各种状态变更后仍能保持一致。
值对象(Value Object):一种特殊的实体,没有自己的状态和生命周期,用属性标识,任何属性的变化都视为新的对象。
聚合(Aggregate):一组生命周期一致的实体集合,表达统一的业务意义,其中有且只有一个聚合根,是聚合的核心对象。
聚合根(Aggregate Root):聚合中最核心的对象,是聚合的领航员,用于管理聚合,实现发现、持久化聚合的作用。
界限上下文(Bounded Context):由统一业务目标和概念的聚合组成的集合,用于识别上下文,避免模型的不正确复用带来的问题。
服务(Service):领域模型的操作者,承载领域的业务规则,用于处理业务逻辑,让逻辑更为清晰明了。
模块(Module):同领域的类或者对象组成的集合,模块的划分没有固定的模式,可以根据业务逻辑的复杂程度进行划分。
工厂(Factory):以构建模型为职责的类或方法,可以把不同的业务参数转化为领域模型。
仓库(Repository):以持久化领域模型为职责的类,用于屏蔽业务逻辑和持久化基础设施的差异。
DDD的特点
基于充血模型的面向对象开发
贫血模型:
定义对象的简单的属性值,没有业务逻辑上的方法(个人理解)
MVC模式开发是是面向过程的编程方式,符合人类大脑逻辑。定义DTO,定义数据库Model,BO等,对其进行get set方法,然后通过service 对Bo对象进行操作,最后通过copy属性持久化数据库和DTO传输。
充血模型:
就是我们在定义属性的同时也会定义方法,我们的属性是可以通过某些方式直接得到属性值,那我们也就可以在对象中嵌入方法直接创建出一个具有属性值的对象。也就是说这个对象不再需要我们在进行进一步的操作,这也就复合了OOP的三大特性之一的封装
参考DDD的部分概念落地方案
借鉴到的DDD的思路,避免循环依赖或者使代码接口清晰,延缓腐化
1、进行领域划分,不同领域的服务之间不能相互注入,但可以通过别的方式来调用,把他当做跨微服务调用,通过在防腐层的xxxLocalclient调用查询相关或者走消息总线的事件方式执行操作相关的动作
2、领域对象实体
3、聚合:把操同一领域数据库的操作分为查询xxxquery和执行xxxexcute2个类
4、对领域相关数据的转化固定放在data层:DTO转entity,entity转VO等的数据处理,统一放置
interface(接口层)
- 很薄的一层
- 类似于MVC中的controller层 只能直接注入app层
application(应用层)
- 很薄的一层
- 注入领域对象,可以设置状态参数(领域层是无状态的,可以在app层设置用户状态,系统标志等等参数)调用领域服务
domain(领域服务层)
- Aservice 领域服务:定义领域方法,只能注入execute、query聚合根来操作持久层
- A1子领域
- A2子领域
- transfer层 领域内部之前通过该层调用 如 A1service -> A2transfer
- repository 存放领域内部仓库,操作持久化层
- dao 存放Mybatis Mapper接口和实现的XML文件
- data(可选)查询前后的数据计算、转化
- execute聚合根 定义所有增删改操作
- query聚合根 定义所有查询操作
- Aservice 领域服务:定义领域方法,只能注入execute、query聚合根来操作持久层
infrastructure(基础设施层)(配置、自研组件、缓存、防腐层(client)、工具包)
client
- remote
- 外围、外部服务client客户端
- native 不同领域对外开放的跨领域本地客户端 比如 A调用B Aservice -> BLocalClient
- BLocalClient
- ALocalClient
- remote
helper 工具类包
- config 引入各组件的配置
component 存放着系统无关、可以随时迁移的自定义组件
- common 存放着系统无关、可以随时迁移的实体、常量类、异常类
bus(消息总线层)
- remote
- 外围MQ等
- native
- 跨领域操作的事件监听
- remote
DDD代码编排:
interfaces->
- application->
- domainService->
- Repository(聚合跟DeviceExecuteRepo)->
- DeviceMapper->
- DeviceDao->DeviceDao.xml
- DeviceMapper->
- Repository(聚合跟DeviceExecuteRepo)->
- domainService->
- 发布事件
- domainService->
- application->
Job/Mq/Eventlistener 监听到事件或MQ->
- application->
- domainService->
- 业务逻辑
- domainService->
- application->

DDD可指导单体项目和微服务架构
微服务架构治标不治本
即便在微服务架构下,比如订单服务部署了多个节点,也避免不了每个节点内代码的复杂和凌乱,因此,在DDD指导下,无论单体还是微服务架构下,每个领域后续都可拆分或者当成一个微服务来看待






DDD与中台

DDD并非银弹

数据中台的定义:https://www.sohu.com/a/425913998_114819
在数据应用和统计分散化的背景下,通过建设统一的数据服务体系,结合业务、安全、风控等相关诉求,完成数据的采集、清晰、建模等行为,并提供准确以及及时的数据服务、以满足企业不断复杂变化的数据统计与数据应用的需求
实例一:今年我们的库存周转率如何协调财务、库存、运营的口径或者标准
实例二:如何统一提供sku管理和服务(商品中台)
