Question

我想先用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）Impex.Domain

2）Impex.Storage

3）Impex.Business

4）Impex.UI

所以我将有4层，那些是域，存储，业务和UI。存储，业务和UI这3层将有Domain层的参考，因为这3层Storage，Business和UI可能会使用域类。

UI会将数据传递到业务层并从业务层接收数据。业务层将再次与存储层对话，其中EF代码将首先实现与DB交互。

如果我可以在4层之后成功完成我的项目，那么人们应该考虑我的项目是否基于DDD模式？

告诉我，我正在思考正确的方式。请告诉我你的所有建议和指导。如果有人能预见到任何问题，那么请详细了解我。感谢

Answer 1

您的问题似乎主要围绕您的解决方案的结构，就像我们行业中的大多数事情一旦您理解了事物的原理（在这种情况下为DDD），结构似乎可以自行解决。

我会指出一些可以帮助你的事情

1）Impex.Domain

保持您的实体清洁，不要引用此项目中的EF
在您的实体中捕获您的业务逻辑＆amp;聚合而不是在“业务”层中，您的实体应该响应事件和操作，而不是让“层”告诉它要做什么

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

这样的事情

employee.takeLeave(days)

而不是

employee.daysOff = days;

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

2）Impex.Storage

由于您使用的是EF（并且不会污染具有EF相关属性的域模型），因此您必须使用Fluent Api配置您的EF模型（请参阅msdn，ef tuts和特别需要SO来获得一些想法，这里需要配置主键和索引。

像

这样的东西

modelBuilder.Entity<Employee>().HasKey(t => t.EmployeeID);

除此之外没有任何东西使用标准存储库模式等。

3）Impex.Business＆amp; Impex.UI

如第1点所述，拥有business图层是没有意义的，而这个图层的内容是Application或Service图层，在这里您可以加载实体或聚合并调用要完成的工作。
该图层的责任还包括在ViewModels＆amp; / OR Request＆amp;响应POCO（发送到您的UI / Api或从您的UI / Api发送），您不会在域边界之外公开您的域模型，请参阅hexagonal architecture

最后一点：

DDD没有规定架构！这是一套指导您的原则，但只要您遵守DDD的租户，您就可以实现您喜欢的1层，3层，CQRS或任何其他架构模式。

祝你好运。

如何将域类与EF代码第一层分开，并在项目中实现DDD

1 个答案: