距离上次更新已经7天了，只要停一天，就会有第二天，还有第三天，越不写越不知道写什么。这就是惯性的力量，不管是勤奋还是懒惰，都会产生惯性，所以勤奋的人越来越勤奋，懒惰的人越来越懒惰，尖子生越来越霸道，学渣越来越霸道渣男越来越多。久而久之，你会觉得自己根本无法改变自己，总会回到我们习惯的状态。所以，朋友们，我们要警惕惰性。它让我们变得更好，也让我们更糟，但它也让我们变得更糟。不行，我又强迫自己更新了。之所以停止更新，一方面是懒惰的小人打败了辛苦的人，另一方面是时间不够用。下班后的时间就这么少，用这个用不着那个，而且我是一个喜欢写代码的人。一旦我开始编写代码，时间就会很快流失。晚上8点写到12点也是一个时间。转眼间，明天就要上班了，我不可能再熬夜了。熬夜毁了第二天，得不偿失。最近在学习和尝试golang的web开发，已经上手了。从之前的Django的MVC模式，逐渐切换到Golang的DDD模式。我感觉DDD更偏向于面向对象，而MVC更像是一种面向过程的风格。.今天我们就来说说什么是MVC，什么是DDD，它们分别适用于哪些场景。什么是MVC，什么是DDDMVC三层架构中，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，全称是DomainDrivenDesign（简称DDD）。领域驱动设计的概念并不新鲜。因为微服务的兴起而受到大家的关注。微服务是拆分成小服务的大服务。这样就必须划分业务模块，自然加速了领域驱动设计的盛行。DDD开发模型实现的代码也是按照MVC三层架构分层的。Controller层仍然负责暴露API接口，M层仍然负责数据访问，V层负责核心业务逻辑。它和MVC的主要区别是M和V的区别，传统的M只定义了数据的结构，没有定义数据的操作，但是在DDD开发模式下，M不仅定义了数据的结构数据，还定义了对数据的操作。比如Django的M和V可能是这样：='user'verbose_name='用户信息'verbose_name_plural=verbose_nameM#views.pyclassUserViewSet(viewsets.ModelViewSet):"""数据操作、增删改查"""...Golang的M://User.gotypeUserstruct{//数据定义...}//数据操作、增删改查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,uiduint32)(*User,error){...}func(u*User)DeleteAUser(db*gorm.DB,uiduint32)(int64,error){...}Golang的Vfunc(server*Server)DeleteUser(whttp.ResponseWriter,r*http.Request){vars:=mux.Vars(r)user:=models.User{}uid,err:=strconv.ParseUint(vars["id"],10,32)iferr!=nil{responses.ERROR(w,http.StatusBadRequest,err)return}tokenID,err:=auth.ExtractTokenID(r)iferr!=nil{responses.ERROR(w,http.StatusUnauthorized,errors.New("Unauthorized"))return}iftokenID!=0&&tokenID!=uint32(uid){responses.ERROR(w,http.StatusUnauthorized,errors.New(http.StatusText(http.StatusUnauthorized)))return}_,err=user.DeleteAUser(server.DB,uint32(uid))iferr!=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的增删改查操作那么简单，那就没必要费脑筋去精心设计DDD模型，MVC模型足以满足这种简单业务的开发。因为业务比较简单，即使我们使用DDD，模型本身也不包含很多业务逻辑，设计出来的领域模型会比较薄，类似于MVC，意义不大。你可能会问，DDD不就是把一些数据操作放在模型里面吗，为什么适合复杂的业务呢？毫不夸张的说，MVC模式的开发大部分是SQL-Driven开发模式。当我们接到一个后台接口的开发需求时，我们先看看这个接口对应的数据库需要的数据，需要哪些表或者哪些表，然后思考如何写SQL语句来获取这些数据。之后，定义models.py，在views.py中编写视图函数。你可以理解为views.py包含了各种SQL语句。但是，SQL语句不能被重用。即使新的界面开发有一些相同的逻辑，视图函数也只能重写。在DDD开发模式下，我们需要提前明确所有业务，定义领域模型包含的属性和方法。领域模型相当于一个可复用的业务中间层。基于这些先前定义的领域模型完成新功能需求的开发。越是复杂的系统，对代码的复用性和易维护性的要求就越高，我们就越应该在前期设计上花费更多的时间和精力。DDD开发模式只是需要我们前期做大量的业务调研和领域模型设计，所以比较适合这种复杂系统的开发。最后，我通常做网络开发。基本上，我使用MVC架构。连Spring官方的demo也是MVC模式。也就是说，MVC还是主流，因为项目之前是基于MVC架构的，保持不变的代价是最小的。但是，MVC是典型的面向过程的设计，不适用于复杂的系统，比如财务系统、会计系统。DDD架构将数据和操作封装在一起，对数据的操作可以复用。它是面向对象的设计，更适合复杂的业务系统。一句话，简单系统用MVC，复杂系统用DDD。
