DDD「领域驱动设计」分层架构初探

---

前言

基于 DDD 传统分层架构实现。 项目 github地址：https://github.com/WuMortal/DDDSample

这个分层架构是工作中项目正在使用的分层架构，使用了一段时间发现受益匪浅，所以整理好我对该分层架构的一些理解分享给大家，我对于该分层架构还处于学习阶段理解有误的地方请指出。本次会以一个案例来说明各个分层的作用以及他们之间的调用关系，还有本次的重点不在于DDD，因为这个我还未能完全理解，当然避免不了中间会涉及DDD的一些概念。

DDD 简单介绍

DDD 什么？为什么使用 DDD ？

关于这个问题有兴趣的可以自行百度，我相信网络上已经有大量的文章来说明这几个问题。我目前的理解是“业务”，是为了应对现在复杂和多变的业务，是一种开发理念。

这里我就以一个小故事描述吧，有一天你接到任务要实现一个修改用户的功能，非常简单。使用传统三层架构我们会怎么写？

1. 先在 DAL 层添加 UserDAL 然后实现一个 Update(UserEntity user) 方法

2. 接着在 BLL 中添加一个 UserBLL 在实现一个 Update(string email,string pwd ...) 方法。

3. UI 层在调用，OK 完成任务下班回家。

接着你接到一个新的需求就是：需要增加用户修改信息的记录。

你立马在 BLL的 Update 的方法里增加的用户修改信息的操作记录，完成需求。

过了一段时间又来了一个需求：用户改了信息需要通知到管理员，并且用户每天只能修改 3 次信息。

好了之后又经历了几波需求，你的代码也在不断的增加和变化，有一天你接收新的项目或者离开了，那么接收你项目的人完全不清楚这里的业务情况。因为 Update 方法并没有直接的反应出里的业务情况，代码目的不明确。代码变得难以维护。

那么在 DDD 里这些应该怎么做呢？

1. 首先在方法的命名上做出更改既然业务是修改信息那么命名应该是 Modify(string email,string pwd ...)

2. 将用户修改信息的记录代码放在 DomainService（领域服务） 中，当然这里的类、方法命名要直接的反应出业务情况，如：RecordUserModifyDomainService。

3. 对应的通知管理员的代码也应该放入 DomainService 中，DomainService 应该尽量简单一般只做一件事情。

分层架构图

下面是关于 DDD 分层的一些描述，摘抄至之前看过的一片文章。

说明

如上图每个层中其实对应着具体的项，下面将对每个项进行说明。

1. Domain 层分为：Domain 、DomainService 和 IDomainService。

   • 首先 Domain 中包含有 Entity 和 IRepository ，Entity 是你的实体一般对于数据库表但是在某些情况下你也可以冗余一些字段。IRepository 仓储的方法的定义，该层不会有具体的实现。
   • DomainService 和 IDomainService，IDomainService 只是负责表达业务的概念，DomainService 里才是具体业务逻辑代码。在这一层的代码命名上需要注意，我们的命名一般要能直接描述出该代码业务的功能。这里可以参考 DDD 的几个概念：通用语言、领域。

2. Infrastructure 层分为：Repository 和 CrossCutting：

   • Repository 里面就是 Domain 里 IRepository 的具体实现。项目中 RepositoryExtensions.cs 是一个扩展类，将所有的仓储注入容器中，方便我们在项目中使用 DI（依赖注入）。
   • CrossCutting 主要是提供一些各个层通用的东西，如一些枚举、扩展方法、工具类等等。

3. Application 层分为：Application 和 ApplicationContract。

   • ApplicationContract 里主要包含 DTO、ViewModel、IXXXService。DTO 是数据传输对象，主要负责给展现层提供展示数据，DTO 里应该只有值类型存在，当然根据具体情况也可存在其他的 DTO 。ViewModel 用于展现层传入的模型，简单的说 DTO 输出，ViewModel 输入。IXXXService 就是应用层的方法定义。
   • Application 里面主要是用于 实现 ApplicationContract 里的 IXXXService，还有 Entity 和 DTO 的映射也属于该层的工作。ApplicationExtensions.cs 扩展方法是用于实现 DI。

4. Presentation 层里目前只有一个 WebAPI。展现层的代码一般有：对传入模型的校验。

案例

本次以一个用户注册的流程为案例，来简单说明如何使用该分层架构进行项目开发。

1. 首先在 Domain 中建一个 UserEntity，有 Id、Mobile、Name、Age、RegisterDateTime 属性。接着建立 IUserRepository，编写需要定义的方法，这里我定义了一个 GetByMobile(string mobile) 方法。

 1  [Table(Name = "User")]
 2 public class UserEntity
 3 {
 4 [Column(IsIdentity = true)] public Guid Id { get; set; }
 5
 6 public string Mobile { get; set; }
 7
 8 public string Name { get; set; }
 9
10 public int Age { get; set; }
11
12 public DateTime RegisterDateTime { get; set; } = DateTime.Now;
13 }
14
15 public interface IUserRepository : IBasicRepository<UserEntity, Guid> { Task GetByMobileAsync(string mobile); }

IBasicRepository 是使用了 FreeSql，你们可以自己实现。

1. 然后在 Repository 中建 UserRepository 类，该类继承 IUserRepository 并且实现该接口的所有方法。

public class UserRepository : GuidRepository, IUserRepository { public UserRepository(IFreeSql freeSql) : base(freeSql) { }

#region Implementation of IUserRepository

public async Task<UserEntity> GetByMobileAsync(string mobile)
{
    return await this.Where(u => u.Mobile == mobile).FirstAsync();
}

#endregion
}

1. 仓储基本好了后就是 Application ，首先需要在 ApplicationContract 中建 UsesDTO，根据业务情况你也可以建 UserSimpleDTO 、UserDetailDTO。DTO 里包含你需要返回的数据，我这里有 Id、Name、Mobile、Age、ProfilePhotoSrc（头像地址根据 Id 拼接，这里我用 imgage/Id.png 的格式）。

 public class UserDTO {
public Guid Id { get; set; }

public string Name { get; set; }

public string Mobile { get; set; }

public int Age { get; set; }

public string ProfilePhotoSrc { get; set; }
}

1. 添加好 UserDTO 后，然后添加 IUserService.cs 接口，接着在 Application 的 Service 中添加对应的 UserService，并且 UserService 继承 IUserService。

public interface IUserService

{

///

/// 用户注册 ///

///用户名

///手机号

///年龄 ///

Task Register(string userName, string mobile, int age);

List<UserDTO> GetList();
}

public class UserService : IUserService { readonly IUserRepository _userRepository;

public UserService(IUserRepository userRepository)
{
    _userRepository = userRepository;
}

#region Implementation of IUserService

/// <summary>
/// 用户注册
/// </summary>
/// <param name="userName">用户名</param>
/// <param name="mobile">手机</param>
/// <param name="age">年龄</param>
/// <returns></returns>
public async Task<bool> Register(string userName, string mobile, int age)
{
    var userEnity = await _userRepository.GetByMobileAsync(mobile);

    if (userEnity != null)
    {
        return false;
    }

    var addUserEntity = new UserEntity
    {
        Id = Guid.NewGuid(),
        Age = age,
        Name = userName,
        Mobile = mobile
    };

    return await _userRepository.InsertAsync(addUserEntity) != null;
}

public List<UserDTO> GetList()
{
    return _userRepository.Select
        .ToList().ToDTOList();
}

#endregion
}

1. UserServcie 是对应展现层的控制器 UserController ---> IUserService。

2. 最后展现层的 WebAPI 只需要注入 IUserService，就可以开心的使用了。

[HttpPost] public async Task Post()
{
var second = DateTime.Now.Second.ToString("00"); bool isSuccess = await _userService.Register("Wigor", $"188888888{second}", 22);

return Ok(isSuccess);
} 

就这样这个简单的案例就完成了，你可以参考着上面 说明 对比着去看看，当然这里有一些东西并没有体现，如 DomainServie，如果按照 DDD 来说还有 值对象、聚合、通用语言……，对于「通用语言」的话其实上面的小故事就体现出了一点。

结语

就 DDD 而言我这里还有很多东西都没有交代，今后有时间的话会慢慢的写出来。还有我也是在学习 DDD 所以有错的地方请指出，望多多包涵。

在使用这套分层架构的时候碰到了许多问题，这里还要感谢老大的指导，为我解答疑问。

最后附上《实现领域驱动设计》中的一句话：