背景
电商商品流转过程中,商品状态很多,且有很多变化。 目前我们在商品状态时,会往MQ中投递一些消息。
因为topic是收费的,所以我们重要业务会有单独的topic。 其他业务都尽量使用1个topic,然后通过tag来区分消息，这样客户端在拉取的时候可以通过tag在MQ服务端就进行过滤。
现在的问题是: 其他业务使用1个topic,肯定是不合理的,tag会太多了。所以应该有多个topic。 那么自然就有如下问题: 哪些消息应该放到哪一个topic中。这个划分原则是什么?
目前的想法: 这个划分原则应该某种是业务领域。 划分业务领域,一是业务自身的边界，二是我们对业务的理解，三是按照领域驱动设计，其他的域划分。
不论是哪种方法，都需要我们对业务流程进行较为全面的梳理。
然后把业务流程划分为比较合适的子流程。 同时明确其中的领域事件。
整个过程不是一触而就的，需要在一开始设计时，就意识到，划分结果是不断变化和演进的。
这里给几个例子,说明topic和tag使用的典型情况
以下图电商交易场景为例，从客户下单到收到商品这一过程会生产一系列消息，以以下消息为例： 订单消息 支付消息 物流消息 这些消息会发送到Trade_TopicTopic中，被各个不同的系统所订阅，以以下系统为例：
- 交易topic + tags[order,pay,logistics]。整个业务流程,都被不同的消息,切割为不同的小段。这些消息暂且理解为领域消息吧。
我们面临的真实场景是
商品状态变化: 上架,下架,编辑中。
微服务的准备工作，需要充分。
1。一个必要的准备工作，应该是领域事件，更具体的，就是消息需要定下来。 并且这些消息要能推动整个流程的完成。// 场景测试。 2。评价准备工作的标准: 核心的场景流程定下来。 不管最终设计的结果，都需要用这些场景过一遍。