ABP VNext从单体切换到微服务，提供了相当大的便利性，对于各模块内部不要做任何调整，仅需要调整承载体即可。
ABP can help you in that point by offerring a microservice-compatible, strict module architecture where your module is splitted into multiple layers/projects and developed in its own VS solution completely isolated and independent from other modules. Such a developed module is a natural microservice yet it can be easily plugged-in a monolithic application.
分层架构ABP VNext自身提供的分层方式如下图，核心部分是Application、Domain与EntityFrameworkCore层，至于HttpApi.Client与HttpApi都是属于将应用去承载到其他系统之上的。
Controller层在ABP VNext中被削弱了，VNext提供了将Application提供动态Controller，所以可能习惯了将部分逻辑写在控制器中的会有些唐突，但理解就行。
新建空文件夹，取名随意(本次取名GravelService)，用于存放整体项目。
在上一步的空文件夹内新建空白解决方案，可以用VS去生成或是按照dotnet的命令生成。
习惯上按照ABP VNext给定的微服务Demo中的格式创建三个文件夹，思路清晰。当然提供的微服务Demo还有更多文件夹，但是这次只关注这三个。
设计三个限界上下文并绘制上下文映射。依照常见的订单、产品与客户划分成三个限界上下文。并规划好订单作为下游依赖产品与客户作为的上游。
从官网直接下载三个模块，或是按照命令行去生成(前提是已经安装了ABP CLI)，无论哪种方式，确保准备好就行，依照模块化思想，将其存到modules文件夹下。
如本次准备了三个模块Product，Order，Customer，依照实际需要，可以去精简一下内部文件，此处各模块内部我只留着src和test文件夹。
对于customer模块的src内部，具体生成的文件夹如下，对于其中的HttpApi、HttpApi.Client及MongoDB，我采取了剔除，无需这部分(在稍后的承载体中有同等功能)。
清理之后变得简简单单的。
对于test内部，同样采取剔除无需的HttpApi.CLient、MongoDB文件夹(注：此处的无需只是针对我而言，如果有需要还是留着吧)。
清理之后，层次划分变得简简单单的。
改造下各模块内给定的Sample案例，改造成各模块命名开头，方便加以区分。以Customer模块为例，将自带的Sample案例更名成Customer，仅作该项改动。
对于Order与Product模块内增加一个下游访问上游服务的链路，方便验证从单体跨越到微服务，底层服务的无需任何改动。对于下游访问上游服务的调用形式，了解到的有两种方式。
当前上下文的应用层直接依赖其他上下文的应用服务；
当前上下文设定出防腐层(在限界上下文间增加一层隔离，方便保证依赖限界上下文存在变动时只需更改隔离层)，在防腐层的实现中去依赖或远程调用其他上下文的应用服务；
我个人倾向于增加防腐层，虽然在VNext中并无相关说法。具体使用时，在领域层或应用层增加防腐层接口，及在EF Core层给与防腐层实现，此时的EF Core层，更应该更名为基础设施层，而不单单是作为资源库的形式。
在Order中Domain层增加ServiceClients文件夹用于存放防腐层接口，而在EntityFrameworkCore层增加ServiceClients文件夹用于存放防腐层实现。
在防腐层接口中增加IProductServiceClient。
public interface IProductServiceClient : ITransientDependency { Task<int> GetProductId(); }在防腐层实现中增加ProductServiceClient。
在Order中的EntityFrameworkCore层引用Product模块内的Application.Contracts层。