今天下午在排查一个EF问题时，遇到了个很隐蔽的坑，特此记录。

转换器将实体中属性类型，通过AES加密算法，转换为Base64编码字符串类型，存储到数据库中。当从数据库中读取数据时，再通过AES解密算法，将Base64编码字符串类型转换为实体中属性类型。在转换器中，将这些参数设置为静态属性，方便在使用时，进行修改。，则不需要转换为Base64编码字符串类型，直接对二进制数据进行加密和解密。其中有身份证号码IdentificationNumber列，需要加密存储，该如何实现？方法，为User表的IdentificationNumber列，添加值转换器。

为什么要独立成服务？以一个健康医疗系统为例， 这个系统包含了用户模块，问卷的发放与填写，图表显示，报表生成与查看，患者管理等功能，传统的架构如下：随着项目规模的增长，在开发过程中会发现如下问题：各模块之间耦合严重，比如：报表模块引用了问卷，用户，随访，患者管理等几乎所有模块，难以维护 间接引用的情况过多，导致项目分层不明确，容易产生引用分歧，难以维护目前做的就是解耦各个模块之间的强关联状态，通过上一章提到的上下文边界划分方式，我们大致可以将系统的架构改造如下：通过调用者和实现者共

上一章我们完成了小项目的面向服务体系改造，你或许一直在思考一个问题。为什么要将业务独立成微服务？以一个健康医疗系统为例， 这个系统包含了用户模块，问卷的发放与填写，图表显示，报表生成与查看，患者管理等功能，传统的架构如下：随着项目规模的增长，在开发过程中会发现如下问题：各模块之间耦合严重，比如：报表模块引用了问卷，用户，随访，患者管理等几乎所有模块，难以维护 间接引用的情况过多，导致项目分层不明确，容易产生引用分歧，难以维护目前做的就是解耦各个模块之间的强关联状态，通过第一章提到的上下文

上一章我们建立了一个典型的面向领域设计的Abp小项目，如果按照常规的开发方式，会遇到什么问题呢？先来完善一下这个小项目，在定义好各实体类后，运行Miguration并向数据库里写入一些初始数据。现在整个项目的依赖引用图如下，每一个都有独立的引用路线，互不干涉。简略图如下假设现在有一个需求，MainService业务需要用到Service1和Service2 中的数据，如何操作？在使用Abp框架时，传统开发方式是先建立领域层服务，应用层中调用领域层服务（Manager）并返回给UI

在企业中大型项目中，随着业务的不断拓展，项目发展到一定程度，需要寻求项目的各模块解耦，独立成为微服务。如何实现呢？首先我们先来简单回顾一下Abp框架怎样实现（DDD）领域驱动设计的，Abp框架的全称是:Asp.Net Boilerplate Project（即Asp.Net 的样板项目），我们知道在领域驱动设计中，我们可以将整个系统分为四个大的层次,每一个层次都有其特定的功能，所以整个项目整体结构是非常清楚的。Eric Evans在《领域驱动设计－软件核心复杂性应对之道》这本书中提出了传统的四层架构