说点题外话02｜模式并不是解决方案
2021-07-22 徐昊
《如何落地业务建模》
课程介绍
讲述：徐昊
时长:大小13.45M
你好，我是徐昊。今天我们再来专门说点题外话。
说点题外话系列，是我根据评论区的留言，以及不少读者直接给到编辑的反馈中，挑选出来一些值得回答，但又不好直接回答的问题，然后呢，我会讲讲这些问题背后对应的原则。希望你可以感受到我强烈的暗示，在学完之后，不仅要思考，还要主动去寻找一下答案。
除此之外，我也希望给平淡的连载生活带来一定的现场感。比如今天这篇文章是周四零点推送，那么编辑小姐姐会在周三中午 12 点截止反馈收集。然后呢，我会从中挑选要写的话题，从下午两点开始写，然后录音。这样或多或少可以为专栏课程带来一些不可预知的可能性（比如编辑小姐姐一整个下午都在担心专栏是不是会断更，以及一整个下午，都保持着随时待命的状态）。
言归正传，今天我要讲一讲模式（Pattern）。自从 GoF（Gang of Four）在 1994 年发布设计模式（Design Pattern）以来，模式就成了获得可重用的对象模型的重要手段，而模式语言（Design Language），也成了我们描述架构和解决方案的重要手段。
我知道我们这...
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
精选留言
Oops!置顶2021-07-22夜不能寐，尝试答一下… 1 关联对象，通过将集合逻辑封装到关联对象中的方式解决聚合时性能和逻辑封装之间的矛盾。 2 角色对象，通过将实体在不同上下文中的逻辑封装在不同的角色对象中，解决上下文过载问题。 3 上下文对象，通过显式的对上下文进行建模，将跨域业务逻辑和上下文依赖封装到领域对象中，进一步解决上下文过载问题。 4 能力供应商，通过从基础设施层提取具备业务含义的能力接口纳入到领域层，消除基础设施层，将其转变为能力供应商，参与各层逻辑，解决传统分层下，领域层和基础设施层之间“不正当”的依赖关系破坏了领域层的稳定性的问题。展开作者回复: 课代表你好
31
码农戏码置顶2021-07-22貌似开了点窍，总结一下，有把锤子哪里都是钉子，有了一套解决方案什么问题都能套得上，但不是每个问题都是同一个问题 由具体问题抽象出解决方案，再在解决方案指导下给出处理具体问题具体路径 问题N：N模式 转化为 问题N：1 解决方案 1：N具体模式 这是N:N的关系，必然从一边是推导不出另一边的 文中的每个问题抽象出是要可扩展，解决方案是面向接口编程，但每个问题都不同，所以具体行为也不同，策略模式是应对行为，状态模式是应对状态 解决方案是一个，可问题却各自具象，魔鬼在细节 能力供应商模式也是同样的，从表面看是接口定义在domain,实现在其它地方，保证domain的稳定，形式上跟很多相似，ACL、整洁架构，也就是解决方案相似，但其实解决的具体问题不同，所以不能说能力供应商就是ACL 很多时候程序员不是在编写代码，而是在摸索业务领域知识；也就是从当前的代码去推测当时在解决什么问题，再重新定义问题，进行重构，这是因为知识没有有效传承，或者没有达到代码即模型展开作者回复: 为你鼓掌
12- 梦倚栏杆2021-07-22说的非常对，but现在很多的实际场景就是根据代码来推测当时要解决的问题，也确实容易走偏（在熟悉业务之后，发现当时可能偏了）
作者回复: 需要知识管理
3 
云师兄2021-07-23深呼吸啊😮💨
林铭铭2021-07-23最难的还是如何把问题定义好。共 1 条评论1
冯2021-07-22设计模式不是设计出来的1