What is the difference between Domain Classes and Database Scaffold classes?

Question

What are rules when creating C# Domain Classes in MVC, and how should they differ from Scaffold Database Model Classes?

Database classes are often normalized, for easier crud operation. Are domain classes generally more flat and denormalized?

Additionaly, this article states to separate change tracking temporal table, and remove them from domain classes.

https://softwareengineering.stackexchange.com/questions/363001/separating-the-domain-model-from-the-data-model

Current question is not a duplicate - as this question is more about C# physical materialized classes and not about modelling itself.

What's the difference between Data Modelling and Domain Modelling?

Answer 1

The terms need to be defined better. Your scaffolded EF classes are "entities", hence the "Entity" in Entity Framework. Entities are strictly a class with an identifier. The identity of the class is tied to the identitifer, so two things are equal only if they have the same identifier.

When you start talking about something like a "domain model", that, too, is an entity, but it's a more expansive concept than what EF deals with. A domain entity has behavior and encapsulates business logic. The problem comes when people try to blur the lines between EF's concept of an entity and a domain entity.

In DDD, the infrastructure is completely abstracted. Persistence is not an issue for the domain, but rather for your infrastructure layer. EF is that infrastructure layer. By trying to use the EF entity as a domain entity, you're creating a hard dependency between the domain and the infrastructure, which causes nothing but problems.

As a result, you want to have separate domain entities where you encapsulate your business logic. Then, in your infrastructure layer, you translate these domain entities into corresponding EF entities for the simple purpose of persistence. As such, the EF entities should be very basic, containing only logic that's necessary for persistence, i.e. no business logic.

Answer 2

Domain class:

For me the domain class is how you define your application model.

Like example I have CMS system like Wordpress I will have some model like Post, Comment, Settings, etc...

So those model are the plain POCO object allow you define the shape of your application.

Database Scaffold Classes:

As the name speak for it's self. It's the class that dotnet ef cli tool generate for you. It hold the definition of database like this

 protected override void Up(MigrationBuilder migrationBuilder)
 {
                migrationBuilder.CreateTable(
                    name: "AspNetRoles",
                    columns: table => new
                    {
                        Id = table.Column<string>(nullable: false),
                        Name = table.Column<string>(maxLength: 256, nullable: true),
                        NormalizedName = table.Column<string>(maxLength: 256, nullable: true),
                        ConcurrencyStamp = table.Column<string>(nullable: true),
                        Discriminator = table.Column<string>(nullable: false)
                    },
                    constraints: table =>
                    {
                        table.PrimaryKey("PK_AspNetRoles", x => x.Id);
                    });
}

protected override void Down(MigrationBuilder migrationBuilder)
{
            migrationBuilder.DropTable(
                name: "AspNetRoleClaims");
}

Each time you change your domain class and you run dotnet ef migration add MigrationName it will generate new Database Scaffold Classes that reflect the new change for the new database. Database Scaffold Classes contain 2 method Up and Down. Up will allow you add new table or modifty column. Down is to drop table.