一般做业务架构时，我们先考虑垂直拆分，从大方向上，把不同业务给区分清楚，然后再针对具体业务，按照业务处理流程进行水平拆分
怎么确定业务领域？
第一步就是把领域事件识别出来，这个系统有哪些是人们关心的结果。有了领域事件，下面一个问题是，这些事件是如何产生的，它必然会是某个动作的结果。
第二步就是找出这些动作，也就是引发领域事件的命令。比如：产品已上架是由产品上架这个动作引发的，而订单已下就是由下单这个命令引发的。
第三步就是找出与事件和命令相关的实体或聚合，比如，产品上架就需要有个产品（Product），下单就需要有订单（Order）。
事件风暴是一项团队活动，领域专家与项目团队通过头脑风暴的形式，罗列出领域中所有的领域事件，整合之后形成最终的领域事件集合，然后对每一个事件，标注出导致该事件的命令，再为每一个事件标注出命令发起方的角色。命令可以是用户发起，也可以是第三方系统调用或者定时器触发等，最后对事件进行分类，整理出实体、聚合、聚合根以及限界上下文
领域建模时，我们会根据场景分析过程中产生的领域对象，比如命令、事件等之间关系，找出产生命令的实体，分析实体之间的依赖关系组成聚合，为聚合划定限界上下文，建立领域模型以及模型之间的依赖。领域模型利用限界上下文向上可以指导微服务设计，通过聚合向下可以指导聚合根、实体和值对象的设计。
有了不同的领域划分，我们还要把这些领域映射到解决方案上，这就引出了限界上下文
限界上下文限定了模型的使用边界，它可以成为一个独立的系统。如果对应到微服务中，每一个限界上下文可以对应成一个微服务。
https://tech.meituan.com/2017/12/22/ddd-in-practice.html
https://time.geekbang.org/column/article/267837