码农戏码置顶2021-07-22貌似开了点窍，总结一下，有把锤子哪里都是钉子，有了一套解决方案什么问题都能套得上，但不是每个问题都是同一个问题 由具体问题抽象出解决方案，再在解决方案指导下给出处理具体问题具体路径 问题N：N模式 转化为 问题N：1 解决方案 1：N具体模式 这是N:N的关系，必然从一边是推导不出另一边的 文中的每个问题抽象出是要可扩展，解决方案是面向接口编程，但每个问题都不同，所以具体行为也不同，策略模式是应对行为，状态模式是应对状态 解决方案是一个，可问题却各自具象，魔鬼在细节 能力供应商模式也是同样的，从表面看是接口定义在domain,实现在其它地方，保证domain的稳定，形式上跟很多相似，ACL、整洁架构，也就是解决方案相似，但其实解决的具体问题不同，所以不能说能力供应商就是ACL 很多时候程序员不是在编写代码，而是在摸索业务领域知识；也就是从当前的代码去推测当时在解决什么问题，再重新定义问题，进行重构，这是因为知识没有有效传承，或者没有达到代码即模型作者回复: 为你鼓掌
21
Oops!置顶2021-07-22夜不能寐，尝试答一下… 1 关联对象，通过将集合逻辑封装到关联对象中的方式解决聚合时性能和逻辑封装之间的矛盾。 2 角色对象，通过将实体在不同上下文中的逻辑封装在不同的角色对象中，解决上下文过载问题。 3 上下文对象，通过显式的对上下文进行建模，将跨域业务逻辑和上下文依赖封装到领域对象中，进一步解决上下文过载问题。 4 能力供应商，通过从基础设施层提取具备业务含义的能力接口纳入到领域层，消除基础设施层，将其转变为能力供应商，参与各层逻辑，解决传统分层下，领域层和基础设施层之间“不正当”的依赖关系破坏了领域层的稳定性的问题。作者回复: 课代表你好
42- 梦倚栏杆2021-07-22说的非常对，but现在很多的实际场景就是根据代码来推测当时要解决的问题，也确实容易走偏（在熟悉业务之后，发现当时可能偏了）
作者回复: 需要知识管理
3 
林铭铭2021-07-23最难的还是如何把问题定义好。共 1 条评论1
冯2021-07-22设计模式不是设计出来的1
云川2023-04-03 来自浙江换句话说，如果看代码知道了模式，那就可以确定其需要解决的问题和具体的解决方案。
2012016242022-08-10 来自中国香港策略模式是应对行为，状态模式是应对状态
云师兄2021-07-23深呼吸啊😮💨