​

 在企业中大型项目中，随着业务的不断拓展，项目发展到一定程度，需要寻求项目的各模块解耦，独立成为微服务。如何实现呢？

首先我们先来简单回顾一下Abp框架怎样实现（DDD）领域驱动设计的，Abp框架的全称是:Asp.Net Boilerplate Project（即Asp.Net 的样板项目），我们知道在领域驱动设计中，我们可以将整个系统分为四个大的层次,每一个层次都有其特定的功能，所以整个项目整体结构是非常清楚的。

Eric Evans在《领域驱动设计－软件核心复杂性应对之道》这本书中提出了传统的四层架构模式，这也是Abp框架目前所用到的分层模型，如下图所示：

​

 怎样将模型落地到项目中呢？ 我们先来分析一下Abp官方生成项目中的目录结构。以“MatoProject”为命名空间从Abp官网生成一个原始项目，打开解决方案：

​

可以看到这几个项目，通过分析，分层模型大致对应到具体的项目为：

1. MatoProject.Application:应用层，定义与UI层交互的标准接口内容，包括交互的方式（HttpPost 或者 Get），权限分配（Authorization），定义数据传输对象（Dto）表明上层关心的模型 ，这一层常用于组装数据并返回；
2. MatoProject.Core:领域层，包含了业务对象实体类Entity，一些实体类的操作方法，一些核心的算法等，也就是Abp定义的领域服务（DomainService）,这个是整个应用的核心部分；
3. MatoProject.Web.Host,MatoProject.Web.Core 以及Abp框架本体：基础设施层，提供帮助类，比如ORM以及UnitOfWork的对象，从而为上面更高层次提供基础服务；
4. 调用整个应用层接口的前端项目，视为UI层：负责用户交互的功能，这里我们可以简单理解成前端项目以及其它可以和用户进行交互的可视化方式，这一层只用于进行展示。

其他的MatoProject.EntityFrameworkCore，和MatoProject.Migurator，属于脚手架相关服务，负责搭建实体对应的数据库表结构以及创建种子数据，用于迁移过程中向数据库写入原始数据。

这是Abp对项目的分层，不同的开发人员对DDD的理解不同，项目分层结构亦有不同之处。

基于这个基础项目，假设我们有几个功能要实现，他们的名称分别为MainService，Service1，Service2。这些实现都是属于独立的业务范畴，我们首先在领域层中建立他们的服务：

​

 以及领域模型，MainEntity，Entity1， Entiy2。

​​

 

 

应用层建立各个服务，以及增删查改的封装：

​

基础设施层可以依赖于Abp的项目，还有自定义的帮助类，都丢到Infrastructure项目中 

​

 整个解决方案的结构类似这样：

​

 

回到刚刚的问题，刚才提到MainService，Service1，Service2是独立的业务模块，怎样的业务划分可以独立成业务模块？这就要讨论一个业务的上下文边界（BC）问题

不同的系统或者子系统有各自的模型（算法，数据，行为）。两个系统中业务之间共同依赖的逻辑则是上下文边界，它起到桥梁的作用。

例如客户关系管理系统（CRM），交易记录子系统和客户支持子系统都会调用客户实体、产品实体的属性和数据。这样就产生了上下文边界， 而它们是隶属于各自不同上下文边界，如下图：

 

​

引用自BoundedContext (martinfowler.com)

具体如何落实处理上下文边界的问题呢？在传统的系统中，客户实体、产品实体是被两个子系统引用的，他们之间是强关联状态

下一章开始，介绍如何用面向服务体系的方式，完全解耦模块之间的关联。

​