距离上次更新已经有 7 天了,只要停下来一天,就会有第二天,第三天,越是不写,就越不知道写什么。这就是惯性的力量,无论是勤劳还是懒惰,都会产生惯性,于是勤劳者越来越勤劳,懒惰者越来越懒惰,学霸越来越霸,学渣越来越渣。时间一长,就会觉得自己根本无法改变自己,总会回到我们习以为常的状态。所以,朋友们,一定要警惕惯性,他使我们越来越好,也会使我们越来越坏,这不,我又逼着自己更新了。
之所以停止了更新,一方面是懒惰的小人击败了勤奋,另一方面是因为时间不够用。下班后就那么点时间,用于这个就不能用于那个,而我又是一个喜欢写代码的人,一旦开始写代码,时间就飞快的流失,从晚上 8 点写到晚上 12 点,也是一眨眼的功夫,明天还要上班,我不可能再熬夜。熬夜会把第二天废掉,得不偿失。最近在学习并尝试 golang 的 Web 开发,已经入门了,从以前 Django 的 MVC 模式,也渐渐的切换到了 Golang 的 DDD 模式,感觉 DDD 更具有面向对象风格,而 MVC 更像是一种面向过程的风格。
今天展开来说,什么是 MVC,什么是 DDD,它们分别适合什么样的场景。
什么是 MVC、什么是 DDD
MVC 三层架构中的 M 表示 Model,V 表示 View,C 表示 Controller。它将整个项目分为三层:展示层、逻辑层、数据层。熟悉 Django 的朋友可以这么映射,M 就是我们编写的 models.py 表示数据层,定义数据的存储,而 V 就是 views.py,里面存放着大量的业务逻辑,C 就是 urls.py 控制着路由的访问。前端请求首先访问 Controller,然后是 View,最后是 Model,这就是面向数据访问的过程来定义的架构。
MVC 的缺点就是虽然 M 和 V 是两份文件,但是数据和业务逻辑高度耦合的,也就是说,M 只负责了数据的定义,而数据的操作都在 V,一旦修改了 M,改 V 是真是苦不堪言,这种将数据与操作分离的特点,破坏了面向对象的封装特性,是一种典型的面向过程的编程风格。
与之对应,将数据和操作定义在一起,就是 DDD,全称叫领域驱动设计(Domain Driven Design,简称 DDD),领域驱动设计这个概念并不新颖,早在 2004 年就被提出了,不过现在又被大家重视起来,还是基于微服务的兴起,微服务就是大服务拆分为小服务嘛,这样就要做好业务模块划分,自然也就加速了领域驱动设计的盛行。
DDD 开发模式实现的代码,也是按照 MVC 三层架构分层的。Controller 层还是负责暴露 API 接口,M 层还是负责数据存取,V 层负责核心业务逻辑。它跟 MVC 的主要区别还是 M 和 V 的不同。传统的 M 只定义数据数据的结构,不定义数据的操作,而 DDD 开发模式,M 不仅定义数据的结构,还定义数据的操作。
比如 Django 的 M 和 V 可能是这样的:
M
# models.py
from django.contrib.auth.models import AbstractUser
from django.db import models
# 数据模型的定义
class User(AbstractUser):
"""
数据的定义
"""
...
class Meta:
db_table = 'user'
verbose_name = '用户信息'
verbose_name_plural = verbose_name
M
# views.py
class UserViewSet(viewsets.ModelViewSet):
"""
数据的操作、增删改查
""" ...
Golang 的 M:
// User.go
type User struct {
//数据的定义
...
}
//数据的操作、增删改查
func (u *User) BeforeSave() error {
...
}
func (u *User) Prepare() {
...
}
func (u *User) Save(db *gorm.DB) (*User, error) {
...
}
func (u *User) UpdateAUser(db *gorm.DB, uid uint32) (*User, error) {
...
}
func (u *User) DeleteAUser(db *gorm.DB, uid uint32) (int64, error) {
...
}
Golang 的 V
func (server *Server) DeleteUser(w http.ResponseWriter, r *http.Request) {
vars := mux.Vars(r)
user := models.User{}
uid, err := strconv.ParseUint(vars["id"], 10, 32)
if err != nil {
responses.ERROR(w, http.StatusBadRequest, err)
return
}
tokenID, err := auth.ExtractTokenID(r)
if err != nil {
responses.ERROR(w, http.StatusUnauthorized, errors.New("Unauthorized"))
return
}
if tokenID != 0 && tokenID != uint32(uid) {
responses.ERROR(w, http.StatusUnauthorized, errors.New(http.StatusText(http.StatusUnauthorized)))
return
}
_, err = user.DeleteAUser(server.DB, uint32(uid))
if err != nil {
responses.ERROR(w, http.StatusInternalServerError, err)
return
}
w.Header().Set("Entity", fmt.Sprintf("%d", uid))
responses.JSON(w, http.StatusNoContent, "")
}
里面调用了 M 中的 DeleteAUser,以后修改 Model 时,只需要修改函数 DeleteAUser,而不需要修改 V。
注意,MVC 和 DDD 与编程语言和框架都没有关系,因为正好手边有对应的代码,就拿来用了。
MVC 和 DDD 分别适合什么样的场景?
MVC 适合简单的业务,DDD 适合复杂的业务,为什么这么说呢?
如果系统业务比较简单,简单到就是基于 SQL 的 CRUD 操作,那么根本不需要动脑子精心设计 DDD 模型,MVC 模型就足以应付这种简单业务的开发工作。因为业务比较简单,即便我们使用 DDD,那模型本身包含的业务逻辑也并不会很多,设计出来的领域模型也会比较单薄,跟 MVC 差不多,没有太大意义。
你可能会问,DDD 不就是把部分数据的操作放在了模型里面吗,为什么就适合复杂的业务呢?
不夸张地讲,MVC 模式的开发,大部分都是 SQL 驱动(SQL-Driven)的开发模式。我们接到一个后端接口的开发需求的时候,就去看接口需要的数据对应到数据库中,需要哪张表或者哪几张表,然后思考如何编写 SQL 语句来获取数据。之后就是定义 models.py 编写 views.py 中的视图函数,你可以这么理解,views.py 中就是各种 SQL 语句。而 SQL 语句是不能复用的,新接口开发即使有部分相同的逻辑,也只能重新编写视图函数。
而 DDD 开发模式下,我们需要事先理清楚所有的业务,定义领域模型所包含的属性和方法。领域模型相当于可复用的业务中间层。新功能需求的开发,都基于之前定义好的这些领域模型来完成。越复杂的系统,对代码的复用性、易维护性要求就越高,我们就越应该花更多的时间和精力在前期设计上。DDD 开发模式,正好需要我们前期做大量的业务调研、领域模型设计,所以它更加适合这种复杂系统的开发。
最后的话
平时做 Web 开发,基本上,都是使用 MVC 架构,就连 Spring 的官方 Demo 也是 MVC 模式,也就是说 MVC 仍然是主流,因为项目之前就是 MVC 架构,保持不变的成本最小。
但 MVC 是典型的面向过程风格的设计,不适合复杂的系统,比如金融类系统、账务核算系统。DDD 架构把数据和操作封装在一起,对数据的操作可以复用,是面向对象风格的设计,比较适合复杂的业务系统。
一句话,简单的系统,就用 MVC,复杂的系统就用 DDD。
如果有帮助,还请点赞、转发、在看,感谢阅读。