在企业中大型项目中，随着业务的不断拓展，项目发展到一定程度，需要寻求项目的各模块解耦，独立成为微服务。如何实现呢？
首先我们先来简单回顾一下Abp框架怎样实现（DDD）领域驱动设计的，Abp框架的全称是:Asp.Net Boilerplate Project（即Asp.Net 的样板项目），我们知道在领域驱动设计中，我们可以将整个系统分为四个大的层次,每一个层次都有其特定的功能，所以整个项目整体结构是非常清楚的。
Eric Evans在《领域驱动设计－软件核心复杂性应对之道》这本书中提出了传统的四层架构模式，这也是Abp框架目前所用到的分层模型，如下图所示：
怎样将模型落地到项目中呢？ 我们先来分析一下Abp官方生成项目中的目录结构。以“MatoProject”为命名空间从Abp官网生成一个原始项目，打开解决方案：
可以看到这几个项目，通过分析，分层模型大致对应到具体的项目为：
- MatoProject.Application:应用层，定义与UI层交互的标准接口内容，包括交互的方式（HttpPost 或者 Get），权限分配（Authorization），常用于组装数据并返回；
- MatoProject.Core:领域层，包含了业务对象实体类Entity，一些实体类的操作方法，一些核心的算法等，也就是Abp定义的领域服务（DomainService）,这个是整个应用的核心部分；
- MatoProject.Web.Host,MatoProject.Web.Core 以及Abp框架本体：基础设施层，提供帮助类，比如ORM以及UnitOfWork的对象，从而为上面更高层次提供基础服务；
- 调用整个应用层接口的前端项目，视为UI层：负责用户交互的功能，这里我们可以简单理解成前端项目以及其它可以和用户进行交互的可视化方式，这一层只用于进行展示。
其他的MatoProject.EntityFrameworkCore，和MatoProject.Migurator，属于脚手架相关服务，负责搭建实体对应的数据库表结构以及创建种子数据，用于迁移过程中向数据库写入原始数据。
这是Abp对项目的分层，不同的开发人员对DDD的理解不同，项目分层结构亦有不同之处。
基于这个基础项目，以及对DDD的透彻理解，下一章节将介绍如何结合Abp，进行接口化改造