<返回更多

我们聊聊DDD、SOA、微服务和微内核

2023-12-08  微信公众号  编程一生
加入收藏

DDD、SOA、微服务和微内核,看到经常有人把这几个概念拿出来一起讲。事实上,DDD和其他三个不是一个维度的东西。

DDD其实特别好理解,DDD就是领域来驱动设计嘛,是一种设计思想。很容易又和OOA、OOD和OOP来比较了。这个回头再说。

SOA、微服务和微内核都是架构风格,DDD里能和他们三个放在一起比较的是四层架构和六边形架构。

四层架构

四层架构长这样:

我们聊聊DDD、SOA、微服务和微内核图片

分为用户接口层、应用层、领域层和基础层,四层架构目的是为了解耦,下层不依赖上层,从依赖关系上讲,四层架构的箭头是反过来的。

目前这个架构,在现代系统中,通常用作项目工程模块的设计。就是说更传统的MVC逐渐被淘汰,目前主流就是这种四层架构。有的项目工程会先用限界上下文划分子域,再用四层架构。然后代码结构长这样:

├─interfaces   API接口层
│   ├─dto     视图模型,数据模型定义 vo/dto(大多数情況是一样的)
│   └─controller   控制器,对外提供(Restful)接口
│ 
├─Application   应用层
│   ├─service  应用服务,非核心服务 
│   └─***      others
│ 
├─domAIn   领域层
│   ├─entity        领域实体、聚合根,充血的领域模型 
│   ├─valueobject        领域值对象       
│   └─service  领域服务类,一些不能归属某个具体领域模型的行为
│ 
├─infrastructure  基础设施层
│   ├─po           持久化对象 
│   ├─repository 仓储类,持久化接口&实现,可与ORM映射框架结合
│   ├─dao         数据访问对象 
│   ├─client       feign等调用客户端 
└─  └─factory    工厂类,负责复杂领域对象创建,封装细节

底层实体采用充血模型,有一些聚合,形成聚合根。与存储层的交互封装在仓库中,用DDD工厂来管理仓库。上层会将实体转换成贫血模型再暴露出去。你们项目的结构,架构师是不是这样定义的?

六边形架构

六边形架构很多文章作者把这个架构分成几层,这些都是加上了作者个人的理解。实际上六边形架构又叫洋葱形架构很简单,就是个端口适配器模式。外六边形是技术域,内六边形是业务域。这个常用于一些整体架构中。比如说基于一些基础组件做二次开发。真正的业务实现是组件实现的,有一些专门的维护人员。但是团队中往往会有更多成员在做封装接口暴露给公司内的用户,做高可用或者自动化运维这些通常所说的外层。这个外层就是六边形架构里技术域解决的问题。

我们聊聊DDD、SOA、微服务和微内核图片

SOA和微服务架构

SOA的出现是为了解决功能复用的问题,将一些共通的模块提取出来做成服务。这个我之前在开发中发现不好用,仅次于单体应用时各个模块引入一个common的jar包。因为这些共通的模块很可能适应不了各方面的需求,上层的需求总有一些差异。这样的情况下,这个共通模块就不太好维护了。

服务化的概念使得上世纪就已经产生的DDD得到了大家的关注。因为DDD解决了怎么服务化的问题,就是划分领域。微服务就是服务化之后划分粒度的问题了。

微内核架构

微内核架构又叫插件化架构,包含两类组件:核心系统(core system)和插件模块(plug-in modules)。核心系统负责和业务无关的通用功能,例如模块加载、模块间通信等;插件模块负责实现具体的业务逻辑,例如“学生信息管理”系统中的“手机号注册”功能。

核心系统(Core System)功能一般比较稳定,不会由于业务扩展而不断修改,插件模块需要根据业务功能的发展不断地扩展。微内核的架构本质是将变化部分封装在插件里,从而实现快速灵活扩展的目标,而同时又不影响整体系统的稳定。常见的例子有:Eclipse IDE、Spring、Dubbo。

我做过一个配置化项目。把业务流程划分成模块,会不断有新业务接入进来,很多模块都可以复用。比如业务A需要abc三个模块,业务B需要acde四个模块,那新业务进来只需要进行模块流程的配置。如果需要的模块没有,那就以插件的形式集成进来再进行配置。我们称这个服务采用的是微内核架构,目的就是要让大家把新功能的开发做插件式开发,避免对旧功能的影响,提高系统的稳定性。

关键词:DDD      点击(13)
声明:本站部分内容来自互联网,如有版权侵犯或其他问题请与我们联系,我们将立即删除或处理。
▍相关推荐
更多DDD相关>>>