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

【51CTO.com原创稿件】面试的时候，面试官问：用户在电商网站中购买成功了，那么它在微服务中经历了什么?你该如何作答?
当我傻啊，用户在电商网站购买成功，还在微服务中，那肯定就是有一套微服务架构的电商系统。
设计一套电商系统还不简单?简单想象一下，既然是一个电商系统，有用户去购买，就肯定得有一个用户模块，购买什么东西总不是西北风吧，购买肯定是商品吧，省掉购物车，就得有商品模块吧。
商品总得有库存吧，库存就暂时跟商品放一起吧，什么仓储物流先别管，就当作是虚拟商品好了，反正题目也没说不能是虚拟商品。 ^_^
购买成功了，那就必须有订单吧，加个订单模块，下完单总得支付吧，不付钱人家凭什么把东西给你，那就得有个支付模块。
简单粗暴，四个模块，如上图：

用户模块
商品模块(库存)
订单模块
支付模块

好，几个模块搞定，外加下单流程图：

等等，貌似题目说是微服务，既然是微服务就涉及到拆分服务的问题。
DDD 领域驱动设计
刚刚确实是梳理了一下模块，既然是微服务，就得进行服务的拆分，服务怎么进行拆分呢?
貌似按照刚次梳理模块来划分也是可以的，不过这样好像显得我很是不专业，听说现在很多人都要使用 DDD(领域驱动设计)来指导微服务的拆分。

参考 DDD 的设计， DDD 官方的架构草图，总体架构分为四层：

Infrastructure(基础实施层)
Domain(领域层)
Application(应用层)
Interfaces(表示层，也叫用户界面层或是接口层)

微服务结合 DDD
不过对于领域设计而言，代码层其实不是最重要，最重要的是如何去划分领域，划分好边界。
而对于微服务而言，非常适合从业务上去划分各个 Modules ，划分好各个业务板块，微服务 + DDD ，个人觉得首先从微服务的角度考虑去划分大的业务模块，每个微服务都应该是一个可以独立部署，各司其职的模块。
简单的说，在微服务实际的开发中，结合 DDD 的思想去划分所有属于自己的领域。
实施 DDD 的关键
第一点是使用通过的语言建立所有的聚合，实体，值对象。
第二点也就是最关键的“建模”：
划分“战略建模” ，从一种宏观的角度去审核整个项目，划分出“界限上下文” ，形成具有上帝视角的“上下文映射图” 。
还有一个建模是“战术建模” ，在我们的“战略建模”划分出来的“界限上下文”中进行“聚合” ， “实体” ， “值对象” ，并按照模块分组。
构建电商系统的上下文映射图