How to separate domain classes from EF code first layer and implement DDD in project

Question

i am trying to get control over DDD with EF code first. i saw when people work with EF code first then domain classes reside there in same classes. just see a small example.

   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; }
    }

customer, address, contact and all domain classes are in same project but i want to put all these domain classes in different project.

just see new project hierarchy which i am thinking to implement. all project name will start with my company then do and project name

here it is

1) Impex.Domain

2) Impex.Storage

3) Impex.Business

4) Impex.UI

so i will have 4 layers and those are domain, Storage, Business and UI. Storage, Business and UI these 3 layer will have reference of Domain layer because these 3 layers Storage, Business and UI may use domain classes.

UI will pass data to business layer and received data from business layer. business layer again will talk to Storage layer where EF code first will be implemented to interact with DB.

if i can successfully complete my project following 4 layers then people should consider my project is based on DDD pattern or not ?

so tell me am i thinking right way. please tell me all your suggestion and guidance. if anyone can foresee any problem then also please aware me in details. thanks

Answer 1

Your question seems largely around the structure of your solution, as with most things in our industry once you understand the principles of a thing (DDD in this case) the structure seems to sort it self out.

I would point out a couple of things to help you along your way

1) Impex.Domain

• Keep your entities clean don't reference EF from this project
• Capture your business logic in your entities & aggregates rather than in a 'business' layer, your entities should be responding to events and actions rather than having a 'layer' that tells it what to

As a poor example, do something like

employee.takeLeave(days)

Instead of

employee.daysOff = days;

i.e. Modifying the state of the entity should be captured internally to the entity.

2) Impex.Storage

• Since you are using EF (and not going to pollute your Domain models with EF related attributes) you will have to use the Fluent Api to configure your EF model (see msdn, ef tuts, and SO to get some ideas) in particular, primary keys and indexes will need to be configured here.

Something like

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

• Other than that nothing exiting here use standard repository patters etc.

3) Impex.Business & Impex.UI

• As mentioned in point 1 it doesn't make sense to have a business layer, rather what this layer would be is an Application or Service layer, here you would load the entity or aggregate and invoke the work to be completed.
• Also a responsibility of the layer would be to map between ViewModels &/OR Request & Response POCOs (sent to and from your UI/Api), you would not expose your Domain Models outside of the Domain boundary see hexagonal architecture

Last note:

DDD does not dictate the architecture! It's a set of principles to guide you, but you can implement as a 1 tier, 3 tier, CQRS or anyother architectural pattern you like as long as you adhere to the tenants of DDD.

Good luck.