ddd架构 无法重构_传统三层架构重构DDD实践

最近在学习DDD,说实话挺难的,当然也可能是我基础差的原因,DDD其实是利用面向对象去分析业务的一套方法论,正好我在面向对象这块理解不够深入,于是陷于困境,好在前段时间补了一下,现在开始尝试实践一下DDD

项目的背景是这样的,五年前,由于我需要一个博客来写博客,于是就编写了一个博客程序,是基于经典的MVC+三层架构

由于业务毕竟简单,代码也没多复杂,正好拿来练手

代码结构得还算清晰,分别是 WebUI,Domain,Repository,Model

在重构之前,首先理一理三层架构的优点和缺点,不管三层架构还是多层架构,他们有一个共同点就是关注点分离,层级可替换

三层架构首先将界面分离出来,形成一个独立的层,也可以称为前后端分离,这样子就实现了具体UI的解耦,ui的升级和替换不会影响后端的业务

前后分离之后,再将仓储与业务分离出来,业务层定义仓储的接口,仓储层实现接口,仓储层的最大的作用就是升级替换orm

可以看到Blog源码中Model是所有层都共用一个的,这个时候就会形成一个问题,你在设计Model的时候,必定会考虑数据库里面表结构的设计,查询优化等等一些东西,数据库与跟面向对象是存在天然的失配阻抗的

这个时候你就不能用面向对象的思想去设计模型,只能妥协于数据库

所有层共用一个model,意味着model随时有可能被改变,而你无法知道到底被谁改变了,改变了什么

model中的一些数据是必须按照一定规则去修改的,如果在ui层或仓储层修改,那么就相当于形成了业务泄露,分层的意义也就不存在了

你可能感兴趣的:(ddd架构,无法重构)