忘川彼岸|我只是下了个订单，鬼知道我在微服务里经历了什么？( 二 ) 【51CTO.com原创稿件】面试的时候

先来确定我们的战略核心的领域是什么?我们的目的是什么?
作为一个电商系统，我们的核心肯定是卖出更多的商品，获取更多订单更多的利润，那么销售可以作为我们的一个核心的领域。
这个作为一个明确核心域确立下来：
确定完核心子域后，根据对这个领域的理解划分出各个上下文，然后根据上下文再确定其他的相关领域。
初步我们可以看出围绕销售核心域的包含的几大块内容，价格，销售方式，购买的方式，已经购买。
然后我们对支撑着核心域的子域也做了划分，支撑着核心域的有商品域，用户域，通用域有订单域，物流域，支付域。
回到我们的主题，我们这次没有购物车，也没有各个会员销售价格，把一些上下文拿掉，并建立映射。
领域驱动设计看似简单，其实很难实施，因为在各个环节中都需要对应的领域专家的参加或指导，这样才能设计出最符合实际的上下文映射图。
而且我们花费的精力可能相比以后的数据驱动开发模式更多，但在整体对项目的把控性能上说，领域比数据驱动更加抽象，更加的顶层设计，在对应互联网的多变情况看得更远。
我们将微服务拆分为 5 个领域，分别是：

销售域
商品域
用户域
订单域
支付域

完美，接下来就可以开始开发了。^?_?^

等等，兵马未动，粮草先行;代码未动，图先行，先把时序图画出来。
时序图
一个简单的下单流程，涵盖了几个领域：

完美，接下来就可以开发微服务了。 ^?_?^

等等，微服务的技术栈还未选型。
微服务技术栈选型
服务拆分完了，时序图也画完了，可以开始我们的微服务之旅了，目前主流的微服务有阿里大名鼎鼎的 Dubbo 和 Spring Cloud 全家桶，还有新浪的 Motan 。
比较熟悉的还是 Dubbo 和 Spring Cloud ，也都使用过，究竟应该选用哪一个呢?
因为之前都使用过，做点简单，粗暴的总结。 Dubbo 在很早之前就开始使用，当时的微服务还没有现在这么火，很多理论体系也未完善， Dubbo 更像是一套 RPC 整合框架， Spring Cloud 则更倾向微服务架构的生态。
相比 Dubbo ， Spring Cloud 可以说是微服务一整套的解决方案，在功能上是 Dubbo 的一个超级。
Dubbo 和 Spring Cloud 比喻， Dubbo 架构的微服务就像组装电脑，各个环节自由度很高。 Spring Cloud 更像品牌机。
基于不折腾，简单快捷，更倾向选择 Spring Cloud 。 OK ，就定下来技术栈使用 Spring Cloud ，愉快的决定。

等等，就这么草率就决定用 Spring Cloud 做为微服务，难道不需要把微服务的利弊先弄清楚吗?