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

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

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

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

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

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

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

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

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

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

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

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