不要将API质量视为技术问题，而更多地是系统问题 - matthe
只见树木不见森林的风险。孤立的设计会带来风险。有一天我们醒来，我们没有想象（或预期）的影响。 API 从业人员受过 康威定理 教育，并欣然接受组织结构和 架构 解决方案之间存在对应映射关系
2 年 前
幽默：架构师在哪里？是谁？
很多团队没有专职的 架构 师，但是实际上有一些角色参与了架构决策，根据 康威定理 ，组织架构决定了技术架构，如果管理者确定了系统的体系结构，那么他们实际上就是其架构师。如果程序员确定了
2 年 前
规则引擎并不灵：康威定律不适用于刚性设计 - verraes
软件设计与 康威定理 是两种不同的东西，软件设计是针对软件的，康威定律认为团队组织管理方式决定了软件的设计，因为这两者本身就属于一个大系统。 但是虽然你的团队划分按照康威定律，最终软件设计还是
1 年 前
软件Bug、耦合以及因果推理 - Michael Feathers
： 系统思考无疑是改变生活的事情！ 首先更改实体，然后更改因果关系。 数学和康威定律相撞！ 软件中的大部分错误：从管理和敏捷不善一直到技术欠债，到混乱的代码以及所导致的缺陷，都是因为我们无法直接
4 年 前
DDD与团队拓扑以及微服务之间的关系图 - aleixmorgadas
相应的 微服务 ，认知负载边界=微服务边界。 根据 康威定理 ，组织 架构 决定了技术架构，那么就要逆康威定律，如果你想要一个微服务架构，那么就改造你的团队结构，这就是团队拓扑的由来，团队
2 年 前
幽默：能否将人类群体视为神经元集合的延伸？
研究的心理模型，该模型将人的性格分为两种：理性和非理性，然后再划分四种：理性之思维与情感；非理性之感觉与直觉。提出 康威定理 的Mel Conway认为：以MBTI为例的人格理论和对象建模之间的区
2 年 前
纠结了，微服务和单体你选择哪一个？
定理、领域驱动设计、断路器模式、分布式 缓存 机制、路由跟踪等，不仅 DevOps 文化与微服务紧密结合，才能发挥微服务的全部功能，因此你需要了解CI / CD工具及其文化（自动部署）。团队应该
5 年 前
停止教条式的领域驱动设计 - CodeOpinion
一堆模式。 统一语言与术语 我发现语言是理解边界和定义系统内有界上下文的好方法。一个很好的例子来自 康威定理 的Mel Conway。 当一个政客用“你好吗？”和一个护士用
2 年 前
应对复杂之道：组织架构和技术架构的双解耦
。 反Conway康威定理：软件公司应该对目标架构进行建模 解耦软件和解耦团队如何协调？ 康威定律 指出： “设计系统的组织......会对所提供设计有限制，这些设计结果其实是这些组织的沟通结构的
5 年 前
如何实现DDD事件建模的详细步骤 - goeleven
之间的依存关系应尽可能小。 另外，请确保不违反 康威定理 ，并考虑到您的组织结构，以便每个自治组件也可以在组织内部得到自主支持。 步骤7：确定消息处理模式 现在，从产生的事件模型中，我
2 年 前
软件开发的常见认知规律和原则 - Reflectoring
关注！具有定期用户反馈的快速迭代允许对重要事项进行数据驱动的决策。像基于主干的开发与功能标记这样的实践可以帮助软件团队实现目标。 破窗定理 破碎的窗户会招致故意破坏，因此很快就会损坏所有窗户
2 年 前
不要从微服务开始！单体是你的朋友？ - arnoldgalovics
，意识到这点是一种进步，你需要有 康威定理 的认知前提。） 更好的故障隔离 这个自然是真的。如果一项服务出现故障，那么只有该服务会出现故障，对吗？ 虽然这有点真实，但它不是非黑即白
2 年 前
微服务踩坑十大教训 - Dave
。 （banq注：也就是说，使用数据层的服务层才更应该被切割成微服务，这种切割是根据 康威定理 的团队结构决定技术架构的理论，只有首先切割团队，才能实现微服务，最后切割数据层） 例如：您的公司应该有
2 年 前