• Kǎfκã²⁰²⁰
    2019-04-01
    万维钢有期节目里提到芯片设计时讲到了分层以及模型的概念。分层或模型,实质是因为人的认知能力有限不得已而为之的。学习计算机,我们都知道晶体管,即便早就忘了它的原理。实际上晶体管涉及非常深奥的物理学知识,这是绝大多数人一辈子都不需要了解的物理学。抛开复杂艰深的物理学,晶体管的本质却很简单,它就是一个包含通和不通两个状态的开关,这就是它构建的模型。

    在开关的模型基础之上,信息论的创立者香农用一篇硕士论文构建了逻辑门这层。他证明了可以用最简单的开关,实现所有逻辑运算。

    逻辑运算层次之上,就是我们所知道的CPU模型。再往上,就是我们所熟悉的信息世界
    展开

    作者回复: 同是精英日课的读者,这篇内容还真的是受到万老师的影响写下的。

    
     24
  • Wei
    2019-04-04
    分享一下自己的经历,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/小密圈 之类的以便课程结束后能继续与老师和各位同行交流。 谢谢
    展开

    作者回复: 多谢你的分享!后续的安排看编辑怎么协调吧。

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

    作者回复: 道理很简单,痛过才知道。

    
     3
  • 码农Kevin亮
    2019-09-02
    请问老师,在jdk的集合框架中常常会在实现类内部维护一个内部类,比如HashMap内部有个Node内部类,这算领域对象么?

    作者回复: 在通常的讨论中,这是不算的。

    
     2
  • kevin
    2019-04-07
    从分层一步步说到领域层的设计重要性,学起来很过瘾。文末留言万老师关于晶体管的设计很精彩

    作者回复: 欢迎把它分享给你的朋友!

    
     2
  • desmond
    2019-04-02
    学了REST和DDD,感觉两者有相通的地方:两者都以数据(一个是资源,另外一个是领域对象)为中心,并制定一套标准的数据操作(一个是HTTP Verb,另外一个我项目主要用JPA这一套);而核心是业务建模。

    作者回复: 你的理解很棒!

    
     1
  • 丿淡忘
    2019-04-01
    老师你好,就是我现在在开发的时候有些困惑,我将界面逻辑层(界面数据显示)
    业务逻辑层(具体业务逻辑功能实现)分出来后,但像支持这些业务的一些服务,比如 通讯服务,数据缓存服务,这些算是工具,还是说也可以分为一些单独的层,还有像界面显示的数据我需要给界面单独提供一些界面显示的数据结构,还是直接使用逻辑层里面的数据结构,还是说这些数据结构单独拆分出来也可以作为一层

    作者回复: 看六边形架构的图,通信服务属于六边形架构的适配器。

    
     1
  • Jxin
    2019-04-01
    对项目中变化代码和稳定代码的拆分。按特性归类成变化层和稳定层,中间用门面或适配器对接。针对变化层提炼出抽象层用装饰者模式或抽象工厂实现多态

    作者回复: 学习 DDD,建立模型概念,你就不纠结于这里的设计模式了。

    
     1
  • shniu
    2019-04-01
    目前对DDD还是一头雾水,尤其对领域模型的抽象和划分,郑老师能不能分析一些实际的案例,这样能有一个更直观的体验
    
     1
  • 丁丁历险记
    2019-11-18
    不知道ror 死掉没。。。
    
    
  • 旭东
    2019-10-01
    分层是为了更好的抽象,区分出程序中的不变点与与易变点,集中精力优化抽象不变点,以便更好的复用不变点逻辑。尽可能的快速添加和修改易变逻辑响应业务变更需求

    个人认为:分层设计有点像代码设计模式里的模板设计模式。但分层设计更像是代码组织的模板,功能和交互层面的分组的模板。分层设计不但做到代码的分层也促进了分工合作,从而达到快速,简单,高效开发的目的
    
    
  • 春之绿野
    2019-09-15
    文章有些地方看不懂,不太懂领域对象什么的
    
    
  • 春之绿野
    2019-09-15
    很多技术都是吧,都是为了把一些通用的基础的功能抽象出来,Robot 框架也是,提供了很多实现基础功能的类库,通过这些基础的关键字可以组成新的关键字,再由关键字组成更复杂的关键字,我们只用关心怎么实现功能,而这些关键字怎么调用,编译,log和结果怎么一层层展示,这些都由框架实现了。
    
    
  • Rainbow福才
    2019-04-10
    分层架构设计的目的:
    1. 提炼抽象,构建好领域模型。
    2. 降低软件开发和维护成本。
    3. 扩展性更好。
    
    
  • Sudouble
    2019-04-07
    以前总是在追逐优雅的设计方案,全让未估计到为什么要这么设计。静下心来,去看问题的本质,这是我这一节学到的~!

    作者回复: 祝你学有所成

    
    
  • 毅
    2019-04-06
    跟过一段时间微软的silverlight,一开始听说是wpf的子集,后来又有人辟谣说除了使用xaml等形似之处外差别很大的。自己也看过两者的源码,就抽象能力和程度看还是正宗wpf强大,虽然不是业务框架,但从开发工具角度来看,它的基于自身定位及领域的体系设计还是值得称道的。曾经有一段时间里java和.net相互diss的厉害,现在看来在道的层面是可以和谐共处的,只是术上各有各的呈现罢了。
    
    
  • 大力
    2019-04-05
    微服务中的数据访问层,有可能跟访问数据库一点关系都没有,而只是一层调用http请求去访问其他微服务的封装,但它的原理其实跟传统的分层结构应该是一致的。
    
    
  • 小小
    2019-04-04
    产品,开发,测试,运维,运营等岗位也属于分层,不同技术栈的人,组成完备技术体系。

    作者回复: 这个理解比较……跨界

     1
    
  • hua168
    2019-04-02
    拿java来说,在MVC分层架构中,Controller 和 Service界限是怎么区别的?
    我理解是:
    M:DAO层,编写数据库连接
    C: 控制层,主要是写业务方法,方法中包含对数据库的一些操作
    V: 展示层,主要是展示

    哪服务层在哪里?服务层=Controller?也不对呀

    MVC原理图网上有很多,下面连接的对吗?
    http://i1.excel99.com/x3edf03d1838280c01dc489d36d78b81a1099d52b.jpg
    展开
    
    
我们在线,来聊聊吧