从以上两点的描述可以看出，战略设计从业务视角出发，而架构服务于业务，两者都需要从业务出发，DDD战略设计与微服务都有同样的设计思想：分而治之、化繁为简，那么战略设计的思想完全可以作为微服务架构设计的指导思想，此时此刻此场景不谋而合。
分层架构也可以叫N层架构（N>=2），其实本质在于划分职责、隔离关注点，保证各层之间的差异足够清晰，边界足够明显，其特点自顶向下依赖，逐层传递。
首先我按照分层架构的思想以纵向维度拆分，主要共分5层，UI层、聚合API服务层、基础业务API服务层、基础设施层、数据库层。
调用链路自顶往下，用户-->UI-->API网关-->聚合API服务-->Consul+Consul Template+Nginx-->业务API服务-->数据库
UI层依赖于聚合API服务层，操作与接口11对应，主要负责可见即可得的工作：数据展示、交互动画等。
入站API网关主要负责聚合API服务层内外网隔离、入站规则控制，防止外部大流量冲垮内部服务。
聚合API服务层被UI层依赖，依赖于基础业务API服务层，主要负责基础业务API服务层的接口的逻辑组合，不直连数据库，可通过API网关暴露给UI层调用。
注册服务中心记录基础业务API服务层的服务IP列表，内网使用，衔接聚合API服务层与基础业务API服务层。
基础业务API服务层，被聚合API服务层依赖，依赖于数据库层，可做具体的数据库读写处理，内网使用，同层服务之间不互相依赖引用。
数据库层包括非关系型数据库与关系型数据库。
基础设施服务层可被所有层都依赖，如果被UI层依赖则通过API网关暴露，如果被内网服务依赖则通过注册发现，可直连数据库。
出站API网关主要负责基础设施服务层内外网隔离，转发第三方开放API请求，出站规则控制，防止被无法把控的第三方服务而拖垮内部服务。
横向拆分接下来，我们可以通过DDD划分领域的方式进行服务的横向维度的拆分。举个例子：
我们平台拥有三种不同业务领域的系统：客户中心、企业管理系统、内部管理系统。
那么，聚合API服务层则拥有客户系统API服务、企业管理系统API服务，内部管理系统API服务。
客户中心的拥有客户信息管理、支付、订单管理等业务模块。
企业管理系统拥有订单管理、权限管理、支付、仓储等业务模块。
内部管理系统拥有权限管理、报表、账户管理等业务模块。
所有系统涉及到自定义订单号、消息推送等业务。
从以上得知，核心域包括仓储、订单业务、客户信息。通用域包括权限管理、账户认证、支付模块、消息推送等。支撑域包括自定义订单号。
因此基础业务API层可以划分：仓储API服务、订单API服务、客户API服务、权限API服务、认证API服务，支付API服务。
基础设施API层可以划分：ID发号API服务，消息推送API服务。
如果随着业务继续扩大，团队人数增多，则可以更加的细分，例如仓储拆分成快运、集运等。支付拆分成微信支付、支付宝等。
项目示例上一篇《.Net微服务实战之技术选型篇》我整理了我们公司使用的框架开源到了github，这次我拿了部分业务项目作为示例并上传了。
https://github.com/SkyChenSky/Sikiro
首先想说明几点：
1.这个不是标准，只是针对我们公司情况取舍后的结果，每个公司的业务有复杂有简单大家视情况完善自己的项目。
2.为了保护公司原有的业务隐私，我做了部分逻辑的删除，所以大家如果看到不完整的逻辑是正常现象。
3.希望大家把思维放高，不要死抠细节，求同存异。
4.代码在原有的基础上修改了名称和引用路径会有变化，如果有问题随时在评论和github反馈给我。