如何将领域类从EF代码第一层分离出来，并在工程中实现DDD

本文关键字：分离出 一层 DDD 实现 程中 代码 EF | 更新日期: 2023-09-27 18:15:41

我正试图首先用EF代码控制DDD。我看到当人们首先使用EF代码时，域类驻留在相同的类中。请看一个小例子。

   public class TestDBContext : DbContext
    {
        public TestDBContext()
            : base("name=TestDBContext")
        {
        }
        protected override void OnModelCreating(DbModelBuilder modelBuilder)
        {
            //modelBuilder.Configurations.Add(new vwCustomerConfiguration());
            Database.SetInitializer<TestDBContext>(null);
        }
        public DbSet<Customer> Customer { get; set; }
        public DbSet<Addresses> Addresses { get; set; }
        public DbSet<Contacts> Contacts { get; set; }
        public virtual DbSet<vwCustomer> vwCustomers { get; set; }
        public DbSet<vwMyCustomers> vwMyCustomers { get; set; }
    }

客户、地址、联系人和所有的域类都在同一个项目中，但是我想把所有这些域类放在不同的项目中。

只是看到我想要实现的新项目层次结构。所有的项目名称将以我的公司开始，然后做和项目名称

在这里

1)最大。域

2)最大。存储

3)最大。业务

4)最大。UI

所以我将有4层，它们是域，存储，业务和UI。

存储、业务和UI这三个层将引用域层，因为这三个层可能使用域类。 UI将数据传递给业务层，并从业务层接收数据。业务层将再次与存储层对话，在存储层中EF代码将首先实现与DB交互。

如果我能成功完成我的项目以下4层，那么人们应该考虑我的项目是基于DDD模式与否?

告诉我我想得对吗?请告诉我您的建议和指导。如果有人能预见到任何问题，那么也请告知我的细节。由于

如何将领域类从EF代码第一层分离出来，并在工程中实现DDD

你的问题似乎很大程度上围绕着你的解决方案的结构，就像我们行业中的大多数事情一样，一旦你理解了一个事物的原理(在这种情况下是DDD)，结构似乎就会自行整理出来。

我想指出一些事情来帮助你前进的道路

1)最大。域

  • 保持你的实体干净，不要从这个项目引用EF
  • 在实体中捕获业务逻辑&聚合而不是在"业务"层，你的实体应该响应事件和动作，而不是有一个"层"告诉它什么

作为一个糟糕的例子，做一些像

employee.takeLeave(days)
不是

employee.daysOff = days;

。修改实体的状态应该在实体内部捕获。

2)最大。存储

  • 由于您正在使用EF(并且不打算用EF相关属性污染您的域模型)，您将不得不使用Fluent Api来配置您的EF模型(请参阅msdn, EF和SO以获得一些想法)，特别是主键和索引需要在这里配置。

之类的
modelBuilder.Entity<Employee>().HasKey(t => t.EmployeeID);
  • 除此之外，这里没有任何退出使用标准存储库模式等

3)最大。业务,越南。UI

  • 正如第一点所提到的，拥有一个business层是没有意义的，而这个层将是一个Application或Service层，在这里你将加载实体或聚合并调用要完成的工作。
  • 层的另一个责任是在ViewModels &/OR Request &响应poco(从你的UI/Api发送和发送)，你不会在域边界之外暴露你的域模型，参见六边形架构
去年注意:

DDD没有规定体系结构!这是一组指导您的原则，但您可以将其实现为1层、3层、CQRS或任何您喜欢的体系结构模式，只要您坚持DDD的租户。

好运。

相关文章：