Web 开发选 MVC 还是 DDD?

开发 项目管理
MVC 三层架构中的 M 表示 Model,V 表示 View,C 表示 Controller。它将整个项目分为三层:展示层、逻辑层、数据层。熟悉 Django 的朋友可以这么映射,M 就是我们编写的 models.py 表示数据层,定义数据的存储,而 V 就是 views.py,里面存放着大量的业务逻辑,C 就是 urls.py 控制着路由的访问。

距离上次更新已经有 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。

责任编辑:武晓燕 来源: Python七号
相关推荐

2020-11-24 09:50:22

大数据语言go

2022-06-02 08:37:10

架构DDDMVC

2020-10-20 09:07:11

监控PrometheusZabbix

2011-09-04 10:20:44

打印机秘诀

2013-05-23 11:28:46

KVM虚拟化REHL

2021-01-18 18:30:49

服务器开发工具

2019-07-04 09:00:00

Web控制器架构

2013-01-03 14:49:34

BES黑莓移动安全

2013-02-21 10:50:49

KVM虚拟化

2009-05-27 13:25:56

erpIT服务

2019-11-04 09:48:35

KPIOKR管理

2021-01-19 05:26:22

Github ActiJenkinsDevOps

2023-07-04 07:53:53

MVCDDD架构

2011-08-10 14:25:59

2021-01-31 18:58:31

redismemcache源码

2012-09-13 10:44:32

Web设计Web分页架构设计

2018-06-24 09:12:33

redismemcache源码

2018-12-28 09:48:11

SolrElasticSear搜索

2015-02-11 10:37:58

腾讯ROM

2020-12-15 15:21:41

C++JavaPython
点赞
收藏

51CTO技术栈公众号