新项目是基于 ABP vNext 框架进行开发的，所以我要求为每层编写单元测试。在同事为某个仓储编写单元测试的时候，发现了一个奇怪的问题。他的对某个聚合根的 A 字段进行了更新，随后对某个导航属性 B 也进行了变更，最后通过仓储提供的 UpdateAsync() 方法对变更的数据进行持久化。
结果再次查出来的时候，发现聚合根的 A 字段倒是更新了，但是导航属性 B 的内部字段没有进行变更。例如在下面的实例当中，聚合根的 Name 字段变更成功，但是导航属性的 Street 字段变更失败了。
首先执行 yum 命令来安装需要的 zsh 原始程序与 git 程序来 pull 代码。
|
|
安装 oh my zsh 脚本 (这一步需要安装 git)。
|
|
使用 which zsh 查看 zsh 的安装目录，一般都存储在 /usr/bin/zsh 目录下。
|
|
使用 chsh 命令切换使用的 shell 程序。
|
|
在上篇文章里面，我们在 ApplicationService 当中看到了权限检测代码，通过注入 IAuthorizationService 就可以实现权限检测。不过跳转到源码才发现，这个接口是 ASP.NET Core 原生提供的 “基于策略” 的权限验证接口，这就说明 ABP vNext 基于原生的授权验证框架进行了自定义扩展。
让我们来看一下 Volo.Abp.Ddd.Application 项目的依赖结构(权限相关)。
本篇文章下面的内容基本就会围绕上述框架模块展开，本篇文章通篇较长，因为还涉及到 .NET Core Identity 与 IdentityServer4 这两部分。关于这两部分的内容，我会在本篇文章大概讲述 ABP vNext 的实现，关于更加详细的内容，请查阅官方文档或其他博主的博客。
在使用 DevExpress 开发 WinForm 程序时，我是使用的默认皮肤进行开发。但客户要求标题栏背景色改为蓝色，标题文字颜色改为白色。
改颜色比较简单，参考了 DevExpress Support 的说明，通过获取皮肤更改 BackColor 和 ForeColor 就可以实现。不过更改之后，发现在低分屏下面，标题文字出现模糊的情况。
ABP vNext 针对于应用服务层，为我们单独设计了一个模块进行实现，即 Volo.Abp.Ddd.Application 模块。
PS：最近博主也是在恶补 DDD 相关的知识，这里推荐大家看一下 ThoughtWorks 的 DDD 相关文章。
关于 DDD 相关的著作，我这儿还是推荐经典的那三本**《领域驱动设计：软件核心复杂性应对之道》、《实现领域驱动设计》、《领域驱动设计精粹》**。
DDD 的学习整体来说是比较枯燥的，而且偏理论化的知识。所以需要结合大量实例来看，反复对照书中的概念加深理解。不仅要看别人的实例，自己也要尝试运用 DDD 的战略方法和战术方法进行设计。
应用服务层在 DDD 分层架构里面是最顶层的，一般与前端（展示层）打交道的都是应用服务层。常规的开发人员，如果没有遵循 DDD 理论来进行开发的话，应用服务层是十分臃肿的，里面全是业务逻辑。而领域层里面则是空无一物，全是贫血的领域模型对象。这种模式被称之为 贫血领域模型模式，这是一个 反模式。
这里我就不再赘述应用服务层与 DDD 之间的关系了，在这里你可以看作它是一个 API 接口实现类，你所有对外开放的接口都是通过应用服务层暴露的，接口的方法应该与用例相对应。