领域驱动设计，其实已经是一个很古老的概念了，但它的复杂度依旧让学习的人头疼不已。
互联网关于领域驱动的文章有很多，每一篇写的都很好，理解领域驱动设计的人都看的懂。
不过，这些文章对于那些初学者而言，还是如同天书一样。
买本驱动领域的书来看？别逗了，这可不是C#语法入门，哪里有书能写明白的。
想学会领域驱动设计，只有一途——实践，不断的实践。
领域驱动设计是什么？
领域驱动设计就是我们俗称的DDD，英文全拼是Domain-Driven Design。
我认为，理解领域驱动设计的第一步是，顾名思义；所以，让我们先直白的通过名字来解释看看。
领域驱动设计：用业务领域来做模块分割，以领域为核心思想设计框架，用设计好的领域来驱动系统实现。
如何？这样是不是就好理解了。
其实，领域驱动设计，和我们之前常用的模型驱动设计很相似。其核心区别，也就是一个聚合的概念。
虽然，现在看来，CodeFirst中的聚合太普遍了，但早在十几年前，聚合可是一个让我们头疼的难题，因为那个时代还没有CodeFirst这么便捷的框架。
什么？你不知道聚合是什么？
别担心，我们在后续实现框架的地方，结合代码把这些聚合啦，值对象啦，等等名词一一讲解。
其实，以现在的技术框架的成熟度，聚合这种东西，不理解也就不理解了，无所谓的。
领域驱动设计的意义
虽然，我不想把领域驱动设计搞的那么神秘，但，事实上，领域驱动设计确实挺难学的。
虽然，我们有了CodeFirst这样优秀的框架，但那只是针对使用者，而对设计者而言，CodeFirst并没有减少设计逻辑。所以，想学会领域驱动设计，还是要有一点耐心，并花一点时间，付诸于实践。
虽然，领域驱动设计很复杂，但，我认为它是值得我们付出时间和心血学习的。
因为，驱动领域设计是技术思维的一个分水岭，学会了这种技术思维后，会对框架设计的理解更上一个台阶。
那么，让我们一起做一个领域驱动的框架，在实践中领会这门技艺吧。
领域驱动设计的实现
我们即将编写的框架是基于Entity Framework的，所以越熟悉Entity Framework越好，如果你不熟悉EF，那也没关系，因为我们是从头一步一步编写的。
下面让我们一起编写框架吧。
首先，我们创建项目如下：
接下来我们把相关的DLL放到KibaDDD程序集下待用。
然后我们编写核心代码程序集Repository。
首先为Repository程序集引入外部DLL[EntityFramework，EntityFramework.Extended，EntityFramework.SqlServer，CodeFirstStoredProcs]，同时，再为程序集引入Utility程序集。
然后我们开始设计Repository程序集的布局。
如上图所示，我们建立了Repository程序集的布局，布局中的文件夹及文件作用如下：
TableMapping文件夹：用于存储数据表的映射关系。
TableModel文件夹：用于存储数据表模型。
TableRepository文件夹：用于操作数据表。
DateBaseContext文件：管理数据库的核心文件。
RepositoryStatic文件：存储静态的DateBaseContext对象，供其他程序集调用，实现线程内，使用同一个DateBaseContext对象，减少内存开销。
Repository的实现
TableModel
TableModel中我们建立了一个表——Kiba_User，代码如下：
public partial class Kiba_User { [Key] public int UserId { get; set; } [Required] [StringLength(50)] public string UserName { get; set; } [StringLength(200)] public string UserNickName { get; set; [StringLength(100)] public string Password { get; set; } public int? Age { get; set; } public int? Sex { get; set; } [StringLength(500)] public string Remark { get; set; } }