35 | 总是在说MVC分层架构，但你真的理解分层吗？

万维钢有期节目里提到芯片设计时讲到了分层以及模型的概念。分层或模型，实质是因为人的认知能力有限不得已而为之的。学习计算机，我们都知道晶体管，即便早就忘了它的原理。实际上晶体管涉及非常深奥的物理学知识，这是绝大多数人一辈子都不需要了解的物理学。抛开复杂艰深的物理学，晶体管的本质却很简单，它就是一个包含通和不通两个状态的开关，这就是它构建的模型。 在开关的模型基础之上，信息论的创立者香农用一篇硕士论文构建了逻辑门这层。他证明了可以用最简单的开关，实现所有逻辑运算。 逻辑运算层次之上，就是我们所知道的CPU模型。再往上，就是我们所熟悉的信息世界

文章有些地方看不懂，不太懂领域对象什么的

学了REST和DDD，感觉两者有相通的地方：两者都以数据（一个是资源，另外一个是领域对象）为中心，并制定一套标准的数据操作（一个是HTTP Verb，另外一个我项目主要用JPA这一套）；而核心是业务建模。

分享一下自己的经历，best practices 其实在不同时期有不同的理解，有时候甚至变化很大，我自己也有迷惑的时候。 我是做ror出身的，rails 就是标准的MVC，再加上一个helper目录； 初入行时候接触的项目，controller都很臃肿，后来，提倡的是 thin controller, fat model, 于是大家又把逻辑搬到model里面；于是model又变得非常臃肿，里面包括了很多业务逻辑，耦合太高，写起测试来非常痛苦； 另外，原本helper只应该放关于view的method， 却很快变成了垃圾桶，很多不是view相关的方法都扔在了helper目录下，甚至很多controller要include 其他controller 对应的helper， 只是因为那里定义了一个可以用到的方法。 再后来，有了presenter的概念，helper目录基本就不用了；每个controller都有对应都presenter，再有，就是建立了service的目录，把业务逻辑从model里面抽离处理； 这样的结构稍微清洁了一点，测试也好写了很多。 但是在我看来，我们项目presenter/services这种分层没有什么标准，有些同事还是把这种分层当作万能垃圾桶，什么都建一个，甚至业务/运算都扔在presenter里面；services 的分层也是一个问题，很多只是根据model的来分，而不是业务； 最近有看了一下elixir对应的phoenix ， 它引入了context的概念，更偏重于业务划分， 我感觉这是一个比rails 更合理的分层。 PS：非常喜欢老师的这个课程，收益良多，能否建立微信群/slack/小密圈 之类的以便课程结束后能继续与老师和各位同行交流。 谢谢

老师提到的直接把第三方类库的字段直接使用，导致bug层出不穷，这个真的是深受其害，线上程序莫名bug，原来是第三方修改或者擅自把字段等出现问题，改来改去，最后还是用类似老师提出那种转化本地对象再使用，最后做了类似一个防腐层那种解决问题。实际才出的坑总结到这么个东西，就是类似老师提出的模型概念

老师在这篇文章里其实主要讲的是DDD，文章在讲到Model时，有一个Model，老师没有讲到，那就是ViewModel,即供视图使用的模型。以前我做过总结，模型应该有三种:领域模型(DDD Model)，数据访问模型(Data Access Model)和视图模型(View Model)，请老师指教。

请问老师，在jdk的集合框架中常常会在实现类内部维护一个内部类，比如HashMap内部有个Node内部类，这算领域对象么？

从分层一步步说到领域层的设计重要性，学起来很过瘾。文末留言万老师关于晶体管的设计很精彩

目前对DDD还是一头雾水，尤其对领域模型的抽象和划分，郑老师能不能分析一些实际的案例，这样能有一个更直观的体验

分层 = 抽象，软件系统的横向模块划分，纵向逻辑分层，确实是一种抽象的实际应用