MVC模式和DDD模式对比,谁才是银弹?
目录
MVC模式和DDD模式对比,谁才是银弹?
从DDD的角度看MVC架构的问题
第一层:初出茅庐
第二层:草船借箭(战术设计)
第三层:运筹帷幄(战略设计)
DDD的不足
总结
MVC模式和DDD模式对比,谁才是银弹?
DDD这几年越来越火,资料也很多,大部分的资料都偏向于理论介绍,有给出的代码与传统MVC的三层架构差异较大,再加上大量的新概念很容易让初学者望而却步。本文从MVC架构角度来讲解如何演进到DDD架构。
关注我 code 杂坛,了解更多......
从DDD的角度看MVC架构的问题
代码角度:
瘦实体模型:只起到数据类的作用,业务逻辑散落到service,可维护性越来越差;
面向数据库表编程,而非模型编程;
实体类之间的关系是复杂的网状结构,成为大泥球,牵一发而动全身,导致不敢轻易改代码;
service类承接的所有的业务逻辑,越来越臃肿,很容易出现几千行的service类;
对外接口直接暴露实体模型,导致不必要开放内部逻辑对外暴露,就算有DTO类一般也是实体类的直接copy;
外部依赖层直接从service层调用,字段转换、异常处理大量充斥在service方法中。
项目管理角度:
交付效率:越来越低;
稳定性差:不好测试,代码改动的影响范围不好预估;
理解成本高:新成员介入成本高,长期会导致模块只有一个人最熟悉,离职成本很大。
关注我 code 杂坛,了解更多......
第一层:初出茅庐
以上的问题越来越严重,很多人开始把眼光转向DDD,于是埋头啃了几本大部头的书,对以下概念有了基本的了解:
统一语言
限界上下文
领域、子域、支撑域
聚合、实体、值对象
分层:用户接口层、应用层、领域层、基础层
于是把MVC架构进行了改造,演进成DDD的分层架构。
DDD分层架构:
MVC架构到DDD分层架构的映射:
至此,算了基本入门了DDD架构,扩展性也得到了一定的提升。不过随着业务的发展,不断冒出新的问题:
一段业务逻辑代码,到底应该放到应用层还是领域层?
领域服务当成原来的MVC中的service层,随着业务不断发展,类也在不断膨胀,好像还是老样子啊?
聚合包含多个实体类,这个接口用不到这么多实体,为了性能还是直接写个SQL返回必要的操作吧,不过这样貌似又回到了MVC模式
既然实体类可以包含业务逻辑、领域服务也可以放业务逻辑,那到底放哪里?
资料上说领域层不能有外部依赖,要做到100%单测覆盖,可是我的领域服务中需要用到外部接口、中央缓存等等,那这不就有了外部依赖了吗?
关注我 code 杂坛,了解更多......
第二层:草船借箭(战术设计)
带着问题不断学习他人经验,并不断的尝试,逐渐get到以下技能:
1、领域层
领域(domain)是个模块,包含以下组成部分,传统的service按功能可能拆分到任何一个地方,各司其职。
1个聚合
1到多个实体
若干值对象
多个DomainService
1个Factory:新建聚合
1个Repository:聚合仓储服务
聚合根(AggregateRoot):
聚合本身也是一个实体,聚合可以包含其他实体,其他实体不能脱离聚合而单独提供服务,比如一篇文章下的评论,评论必须从属于文章,没有文章也就没有评论。仓库层(repository)也必须是以聚合为核心提供服务的。
实体可以理解为一张数据库表,必须有主键。
值对象没有主键,依附于实体而存在,比如用户实体下住址对象,一般在数据库中已json字符串的形式存在;最常见的值对象是枚举。
仓库服务(repository):
资源库是聚合的仓储机制,外部世界通过资源库,而且只能通过资源库来完成对聚合的访问。资源库以聚合的整体管理对象。因此,一个聚合只能有一个资源库对象,那就是以聚合根命名的资源库。除此之外的其他对象,都不应该提供资源库对象。仓储服务的实现一般有Spring Data JPA、Mybatis两种方式。
如果是用Spring Data JPA实现,直接使用JPA注解@OneToOne、@OneToMany,配合fetch配置,即可一个方法查询出所有的关联实体。
如果是用Mybatis实现,那么repository需要加入多个mapper的引用,再手动做拼装。
这里有一个经典的Hibernate笛卡尔积问题,答案是在聚合根中,一般不会加在大量的关联实体对象。如果确实需要查询关联对象而关联对象又比较多怎么办呢?在DDD中有一个CQRS(Command-Query Responsibility Segregation)模式,是一种读写分离模式,在此场景中需要将查询操作放到查询命令中分页查询。
当然CQRS也是一个很复杂模式,不应照搬他人方案,而是根据自己的业务场景选择适合自己的方案,以下列举了CQRS的几种应用模式:
单服务/跨服务 | 共享模型/不同模型 | 共享存储/不同存储 | 适用场景 |
---|---|---|---|
单服务 | 共享模型 | 共享存储 | 不算CQRS,但对于很多中小型项目已经足够 |
单服务 | 不同模型 | 共享存储 | 适用于查询比较复杂的场景 |
单服务 | 不同模型 | 不同存储 | 适用于查询比较复杂且对查询效率要求较高的场景 |
跨服务 | 不同模型 | 不同存储 | 主要用于微服务中需要对多个服务进行聚合查询的场景 |
工厂服务(factory):
作用是创建聚合,只传入必要的参数,工厂服务内部隐藏复杂的创建逻辑。简单的聚合可以直接通过new、静态方法等创建,不是必须由factory创建。
领域服务:
单个实体对象能处理的逻辑放到实体里,多个实体或有交互的场景放到领域服务里。
领域服务可不可以调用仓储层或外部接口?可以,但不能直接和领域服务代码放一起,领域服务模块存放API,实现放基础层(infrastructure)。
领域服务对象不建议直接以聚合名+DomainService命名,而要以操作命令关联,比如用户保存服务命名为:UserSaveService, 审核服务:UserAuditSerivce。
2、应用层
应用层通过应用服务接口来暴露系统的全部功能。在应用服务的实现中,它负责编排和转发,它将要实现的功能委托给一个或多个领域对象来实现,它本身只负责处理业务用例的执行顺序以及结果的拼装。通过这样一种方式,它隐藏了领域层的复杂性及其内部实现机制。
比如下订单服务的方法:
public void submitOrder(Long orderId) {Order order = OrderFetchService.fetchById(orderId); //获取订单对象OrderCheckSerivce.check(order); //验证订单是否有效OrderSubmitSerivce.submit(order); //提交订单ShoppingCartClearService.clear(order); //移除购物车中已购商品NotifySerivce.emailNotify(order.getUser()); //发送邮件通知买家
}
对于复杂的业务来说,应用层也有几种模式:
编排服务:最典型比如Drools;
Command、Query命令模式;
业务按Rhase、Step逐层拆分模式;
3、Maven模块划分
基础层是比较简单一层,不过这里还有个比较疑惑的问题:按照DDD的四层架构图去划分Maven模块,基础层是最上的一层,但是基础层也要包含基础组件供其他层使用,这时基础层应该是放到最下层,直接按照这样构建Maven模块会造成循环依赖。
相比来说,另一个架构图更准确一些,不过依然没有直观体现Maven模块如何划分。
我的最佳实践是将基础层拆分两部分,一部分是基础的组件+仓储API,一部分是实现,maven模块划分图如下所示:
第三层:运筹帷幄(战略设计)
经过以上的两层的磨炼,恭喜你把DDD战术都学习完了,应付日常的代码开发也够了,不过作为架构师来说,探索的道路还不能止步于此,接下来会DDD战略部分。战略部分关注点有3个:
1、统一语言
统一语言的重要性可以根据Jeff Patton 在《用户故事地图》中给出的一副漫画来直观的描述:
统一语言是提炼领域知识的输出结果,也是进行后续需求迭代及重构的基础,统一语言的建立有以下几个要点:
统一语言必须以文档的形式提供出来,并且在整个项目组的各团队达成共识;
统一语言必须每个中文名有对应的英文名,并且在整个技术栈保持一致;
统一语言必须是完整的,包含以下要素:
领域模型的概念与逻辑;
界限上下文(Bounded Context);
系统隐喻;
职责的分层;
模式(patterns)与惯用法。
2、领域划分
以事件风暴的形式(Event Storming),列出所有的用户故事(Use Story),用户故事可通过6W模型来构建,即描写场景的 Who、What、Why、Where、When 与 hoW 六个要素。然后圈选功能相近的部分,就形成了领域,领域又根据职能不同划分为:核心域、支撑域、通用域。
具体的过程有很多参考资料,这里不再细讲,最终的输出是领域划分图,以下是一个保险业务示例:
3、限界上下文
限界上下文包含两部分:上下文(Context)是业务目标,限界(Bounded)则是保护和隔离上下文的边界。
关注我 code 杂坛,了解更多......
比如上图中的实现部分即是限界上下文的边界,虚线部分代表了领域的边界。限界上下文没有统一的划分标准,需要的读者根据自己的业务场景来甄别如何划分。
一个上下文中包含了相同的领域知识,角色在上下文中完成动作目标。
边界体现在以下几方面:
领域逻辑层:确定了领域模型的业务边界,维护了模型的完整性与一致性,从而降低系统的业务复杂度;
团队合作层:限界上下文一般也是用户换分团队的依据;
技术实现层:限界上下文可当成是微服务的划分边界。
DDD的不足
DDD架构作为一套先进的方法论,在很多场景能发挥很大价值,但是DDD也不是银弹。高级的架构师把DDD架构当成一种工具,结合其他架构经验一起为业务服务。
DDD的不足有几个方面:
性能:DDD是基于聚合来组织代码,对于高性能场景下,加载聚合中大量的无用字段会严重影响性能,比如报表场景中,直接写SQL会更简单直接;
事务:DDD中的事务被限定在限界上下文中,跨多个限界上下文的场景需要开发者额外考虑分布式事务问题;
难度系数高,推广成本大:DDD项目需要领域专家专家,且需要特别熟悉业务、建模、OOP,对于管理者来说评估一个人是否真的能胜任也是一件困难的事情。
总结
本文从MVC架构开始讲述了如何从演进到DDD架构,限于篇幅很多DDD的知识点没有讲到,希望大家在实践过程中能灵活运用,尽享DDD给业务带来的价值。
关注我 code 杂坛,了解更多......
MVC模式和DDD模式对比,谁才是银弹?相关推荐
- ART与Dalvik哪个好用 ART模式和Dalvik模式区别对比分析
最新的安卓4.4系统中引入了全新的ART模式吗,相比之前流行已久的Dalvik模式有了很大的改变.最近看到不少安卓手机朋友在问ART与Dalvik哪个好这样的问题,因此笔者今天为大家制作了以下这张AR ...
- 网络/Network - 网络编程 - 高性能 - 单服务器高性能模式[网络模型]及性能对比 - 学习/实践
1.应用场景 主要用于学习单服务器高性能模式及性能对比,尤其是网络模型,这个很重要,并将这些知识在工作中验证,实践,理解,掌握. 2.学习/操作 1.文档阅读 推荐 18 | 单服务器高性能模式:PP ...
- 基于MVC模型和分层模式完成登录和注册
1.MVC概述 Model.view.Controller即模型.视图.控制器.是软件的一种架构模式(Architecture pattern).MVC要实现的目标是将软件的用户界面和业务逻辑分离,可 ...
- 这是一份全面 清晰的架构设计指南:MVC、MVP MVVM模式(含实例讲解)
前言 在Android开发中,当你梳理完需求后,你要做的并不是马上写下你的第一行代码,而是需先设计好整个项目的技术框架 今天,我将全面介绍Android开发中主流的技术框架MVC.MVP 与 MVVM ...
- MVC+LINQToSQL的Repository模式之(二)数据基类
namespace Data.TEST { /// <summary> /// 数据操作基类 /// </summary> public abs ...
- php cli python,PHP MVC框架 CodeIgniter CLI模式简介
PHP MVC框架 CodeIgniter CLI模式简介 分类:PHP_Python| 发布:佚名| 查看: | 发表时间:2014/7/25 让我们以Hello World为例,首先创建一个简单的 ...
- 搜狗浏览器在高速模式下,右键点击才会出现“审查元素”
搜狗浏览器在高速模式下,右键点击才会出现"审查元素", 学习javascript!!!
- 4种常见分支模式解析及优劣对比 | 研发效能提升36计
摘要:4 种常见分支模式解析及优劣对比.团队研发的本质并不是团队规模越大,研发的效率就越高.我们以为团队规模越大,研发效率就会越高,可以做越多的东西,但是我们发现团队规模大到一定程度,整个研发效率是会 ...
- MVC三层架构的模式
大家好,今天给大家分享一下MVC 三层架构的模式 首先你要知道,所谓的MVC就是一种面向于javaee企业级开发的设计模式 这里要强调一点,MVC 不是一种技术,不是一种像spring 那样的框架,它 ...
最新文章
- 三级下拉框连动的数据库版
- iptables命令_程序员最有用的linux命令汇总
- MySQL双向主从复制
- 洛谷P4482 [BJWC2018]Border 的四种求法 字符串,SAM,线段树合并,线段树,树链剖分,DSU on Tree...
- java map对象排序输出_java实现对象的排序(List和Map)
- IBM携手MIT组建新实验室:人工智能将有像人一样的视听功能
- bzoj 4551: [Tjoi2016Heoi2016]树
- .net byte转java byte_「Java知识收集整理」Java语法的基础
- 一文读懂分布式任务调度平台XXL-JOB
- 前端开发技术-promise是什么?
- ACM144-小柯的烦恼zy
- ping ping ping
- 微信小程序项目实例小程序记事本+后台
- 字符串的定义与赋值及初始化
- 树莓派4 使用 SnowBoy 搭建热词唤醒
- win7下Elasticsearch、Kibana安装
- 六牛php工程师,童六牛——安徽工业大学材料学与工程学院教授
- Jedis和Lettuce
- linux 启动脚本
- ip route命令
热门文章
- python实现舒尔特方格
- R语言和Julia以及Python使用Feather包共享数据
- 【历史上的今天】8 月 23 日:万维网面世 30 周年;微信公众平台正式上线;计算机先驱诞生日
- 艺术设计用计算机主板,学艺术设计的用什么电脑比较好
- React-fiber架构的解释
- 台式计算机国标码,在计算机中,国标码是属于什么码?
- 笔记本电脑数字键盘打不出数字的解决方案
- PLC通讯之串口转以太网/WIFI的透传模块(DTU)的专用OPC软件和DLL通讯组件
- The best way to use Xtool X100 PAD2 for FEM programming
- LPC2141芯片解密 芯片解密干什么