微服务解决的其中一个问题就是，将复杂的问题复杂的系统简单化处理，同时反过来，简单的服务做各种组合后又能适应其他复杂的系统。
我认为营销系统也应该如此，包括管理界面设计。
做过数据库的同事应该知道数据库设计时需要尽量避免多对多的关系，一个原因是复杂，另一个原因难以维护。
营销系统的业务、场景也是非常复杂的，如果我们基于复杂的问题复杂化处理，复杂的系统复杂化设计的话，其实也就相当于我们在不停的做业务，但是每个业务之间却没有可重用的服务或代码，也就是一个业务就是一个烟囱，大家都很累，却无法满足快速的市场需求。
以活动权益的关系为例，活动相当于门槛，权益是核心，关系应该是多对一的关系。但是假如我们基于业务考虑: 多个门槛其实对应一个营销活动，OK，我们需求在设计管理界面时，将多个门槛设计到一个界面里，开发人员在开发的时候，使用复杂的代码实现一个活动遍历多个门槛的处理逻辑，可能会这么设计。但是满足门槛了之后需要发放权益，也就形成了活动权益之间的多对多的关系，以后他们会打架的。
另外考虑实际场景，门槛是经常会变，也就意味着活动代码也要经常的变动，很可能每次变动会对历史已支持的门槛造成不兼容。而且管理界面也变的复杂无比，是否真的有必要这么实现呢，实现的代价与收益比是否值得？
网友评论