在程序设计里面，有个名词叫耦合性。
耦合度指程序模块间存在联系的紧密程度，内聚性则是模块内部的相互依赖程度。
低耦合就是模块之间的关联少，越独立耦合度越低。
高内聚就是模块的内容针对干的事情少，功能越单一内聚越高。
我们在设计产品的时候，为了功能的简单行，将两个模块融合在一起。当业务复杂起来的时候，程序猿那边则说改起来很复杂。
“支付订单”、“菜品下单”和“营销模块”的耦合性
做餐饮系统的时候，针对顾客在餐桌上使用硬件平板下单场景，设计点菜流程，最初是将菜品下单与支付订单连在一起。就是用户下单一次，就支付一次。对比电商领域，一个商品列表订单也对应一个支付订单。
而实际场景下用户加饭、加菜的情况占到70%以上。
在同一餐次下面，用户是可以重复下单的，因为可以选择加菜，也可以选择退菜。
另外，本餐次的优惠券的使用要支撑每个支付订单。也就是说你的退菜和加菜的支付订单都要加上营销模块。
基于1对1不适用于现在餐厅消费的场景，所以将支付订单、菜品订单、营销模块分开，都统一关联到餐次下。
这样的好处是：
1、支付订单不与菜品下单关联，只与餐次订单关联
用户不需要及时支付，代码里也不用记住每次的支付状态，例如待支付、已支付，锁定中，已取消等等。
2、支付的实际结算频次下降
因为用户可以选择一次性付款，也可以选择先付款最后再退付款。营销模块是加载在餐次订单下的所有支付订单。
“内容上传”、“内容编辑”、“内容发送”的耦合性
而在做媒体网站的时候，做发表文章的功能。发表文章的本质是将内容发送给不同网站频道。
很自然想到demo功能，填写内容到点击发送。
但可能会有以下场景需要考虑
1、我们要重复发送同一篇文章到不同模块呢？
2、内容是需要有人编辑审核的，内容的投放也是有专门的人员。
3、作者发送的内容会有敏感词怎么办？
那最初的方案能且只能达到：让网站将文章发送给多个频道。
而对于博客来说，后台编辑则没有如此的用户需求，因为是属于个人的东西，最多增加一个草稿箱作为过渡。
而正由于运营者使用场景的多样性，无法在同一个页面上同时完成这么多功能。
这个设计转成技术方案就会很明显感知到“耦合”了，因为这套方案同时包含了“内容上传”、“内容编辑”、“内容下发”，在功能上，产生了“交叉关联”。
我们采用的方案则是将“内容上传”、“内容编辑”、“内容下发”分别独立成一个功能，三者之间存在“调用”的顺序关系，不存在“交叉”的耦合关系。而独立之后，可以更多考虑模块的功能使用场景。
内容上传：
不限作者投稿；
专注于内容创作，强调编辑；
以“内容”作为最小单位；
可记录访问，转发等数据。
内容编辑：
强调查看，用于审核；
强调编辑，用户修改；
内容下发：
可选择投放到不同频道；
记录“发送历史”及“发送状态”；
以“下发行为”作为最小单位；
可重复投放；
那用户体验和功能耦合性的冲突，怎么解决呢？
我们在避免功能耦合的时候，确实会增加一定的操作成本，但“用户体验”更多的是产品经理的自我素养，是一个加分项，而不是价值体现。
用户在使用产品时，通常是为价值买单，而不是为体验买单，尽管我们都很努力，且很刻意的追求用户体验，但当体验与价值产生冲突时，必然会出现“降维”。
