「这是我参与2022首次更文挑战的第7天，活动详情查看：2022首次更文挑战」。
高内聚。这是99%的研发都听过，但是80%的人都做不到或做不好。
我猜想在技术前辈们总结这条原则之前，那时候的一些项目代码看起来可能会很可怕吧。应该有非常多的实现修改会牵一发而动全身的。痛苦不堪的前人提出了高内聚这一原则和理念。
基于这一原则，工程代码设计也会像其他架构设计一样采取“分层设计”，以避免产生过多耦合，现在大家常用的MVC架构就是基于这样一个理念产生的。这里额外说一句，就像前一篇说的原则，我觉得还应该再有一层Data层，用以封装所有的项目的外部依赖，形成DMVC的架构，增加的这个“Data”层非常重要。另外还有一层需要拆分的就是“Cache”层，其他层内都不应该有任何缓存逻辑，有其他机会再展开来说一下这部分。至此整体架构应该是DMVC+C的设计，这个架构看起来像这样：
随着MVC架构的推广演进，大家又发现，这个架构很好，但是还太粗，依然在Model层内会有大量的混乱的耦合，这时候就又有了一个现在特别流行的设计模式：领域驱动设计。DDD提出了大量的建议来尽可能避免Model层内的混乱。
这中间有一种争论，“贫血模式”和“充血模式” 。 这里我想说一下我的立场，我支持“充血模式”，因为它更符合“高内聚”的原则。Entiry就应该有自身动作的方法存在，而不是像很多项目里单独拆出了大量的xxxUtil，这种Util恐怕除了写的人会用以外，项目组内其他协同的人大概率的情况是完全感知不到这个Util的存在啊，除非增加很大的管理成本或沟通成本，为什么不直接把Entity相关的Util直接写到Entity内呢？如下充血模式的代码：
代码块
@Data
public class Entity {
private String fieldA;
private Integer fieldB;
public OtherEntity convert2OtherEntity() {
return new OtherEntity();
}
public void assignFrom(OtherEntity otherEntity) { }
public static Entity parseFrom(OtherEntity otherEntity) {
return new Entity();
}
}
复制代码一个Entity应该包含自身转换的各种动作，如样例中的赋值类方法 assignFrom 、解析类方法 parseFrom 和 转化类方法 convert2xxx。
站在团队协作和技术管理角度，充血模式非常的好，不仅完美的符合“高内聚”原则，还极为有效的降低了项目的管理成本和沟通成本，我们完全不需要有点洁癖似的贫血模式。
在学习或想学习工程设计的同学，可以继续google一下MVC和领域驱动设计去学习了。
希望“今日份十分钟”对高内聚、MVC和领域驱动设计的粗略分享对你有所启发和帮助。
今天附加一个额外的问题，一个是回答昨天一位朋友的疑问，另外一个也算是对过去一周写“十分钟小知识”的一个小结。
昨天朋友问我：“为什么是每天十分钟？不是更长时间，连周末也没有更长时间” 。
1、一开始是为了容易点拿到这个发帖活动的奖品，毕竟略微有点收集癖。
2、另外也是为了刻意的去训练大脑，就像越锻炼身体，身体会越好一样。就像以前做算法竞赛训练一样，我需要刻意的去训练大脑有限时间内快速的归纳总结、演绎抽象和准确简明输出的能力。
这是一个已经内卷非常严重的时期了，既然剧场效应已经起来，而自己又无力改变大环境，那就一起卷起来吧。
身体是内卷之根本，要加强训练，图片里是我现在的身体情况，我感觉应该是能卷过超99%的人吧。
另外就是要好好的锻炼大脑了，一方面能增加内卷竞争力，另外一方面，可以提高做事效率，一定程度的也能减少自己内卷的受累程度。
来，一起努力一起卷起来。
今天的十分钟是坐在教室里写的，这间教室也是我以前听公司财务课的教室。就自然的想起了我最敬爱的徐信忠老师，他真挚热诚的教育之心对我感染很大。他说过要“学一些无用之学”，我很接受这个观点。后续的帖子看情况在后边附录一些技术以外的内容，打破信息茧房很重要，希望能帮你打破一些信息茧房，也希望大家能留言，帮助我打破我的信息茧房。
今天推荐阅读《经济学原理》 曼昆 ，现在是商业社会，了解经济运行原理还是很有必要的，有空了看看。