Why is the infrastructure layer using the domain objects from the core layer as models for DbSets in the DbContext? Doesnt that defeat the whole purpose?

[nabeelfarooqui98]

Hi Im new to DDD in general but seems to me like my SQL tables will be mapped 1:1 to my domain?

I thought DDD meant that while creating the domain I wouldnt need to worry about how its persisted. For example I want to merge some properties of the domain object into a single string column in my DB but using the domain object directly in the DbSet just means the whole model will be created as it is in the SQL database.

Am I missing something here?

[lukehammer]

"I thought DDD meant that while creating the domain, I wouldnt need to worry about how its persisted."

I would say this is half true. Knowing how to persist is still important for the infrastructure project. You are free to save this however you want. but you will need to get to and from your domain entities.

The value statement of DDD is that changes to how you save your data should not effect the structure of your core domain enities.

Core should not know how your data is saved. (but should know the interface that allows saving and retrieving data.)
Infrastructure definitely needs to understand how your data is saved.

[nabeelfarooqui98]

Infrastructure definitely needs to understand how your data is saved.

Yes I agree.

So is it a good thing to create different classes (models) in the infra project which will directly be converted into my database tables? Then have mappers (in the infra layer project) between these models and the domain objects?

But I see that in the core project in some specification there are complex 'includes' happening. Which work on the domain objects. How will those be executed? Seems like the specs dont have anything to do with the custom models in the infra layer

[lukehammer]

"So is it a good thing to create different classes (models) in the infra project which will directly be converted into my database tables? Then have mappers (in the infra layer project) between these models and the domain

I would temper the response here and say, no, it's not necessarily a good thing.

What value are you gaining by creating a second object inside of your infrastructure project?

And that's not being snarky. That's a real question. If there's value in. creating a second set of dtos to map to the database. Go ahead and do it.

But if there is no or little value in creating a second set of objects than this extra work, then don't it.
And if you do create extra objects just for saving to the database, don't let those leak into your domain Project. Which would actually be pretty difficult based on. the project references.

I've been on teams that have done both. And I've never had it explained in a satisfactory matter to me Why creating the second set of objects had value? so I did not like it be caved to the team's standard practices.

Personally do not do it.
well most of the time.

I did have had time where it did create a DTO just for infrastructure because the Domain object had an enum property. And I wanted to it be saved a text on the Database. Back then EF did not have the .builder.HasConversion that it has now.

today I would do this

public void Configure(EntityTypeBuilder<MyEntity> builder)
      {
      builder
          .Property(e => e.Status)
          .HasConversion(
              v => v.ToString(), // Enum to string
              v => (Status)Enum.Parse(typeof(Status), v)); // String to enum
  }

But back then, what I did was I created. a dto just for saving mapped like you suggested. In the mapping I converted the enum to its string representation. And created a reverse mapper to do the opposite. Convert the string back to an enum.

Either way, both of these support the main. idea that you want to enforce, and that is that the domain shouldn't. care about how the data is being saved.

Whether or not creating a whole nother set of objects. is advisable. The answer for me is NO.(Unless you have a really good reason)
Is it allowed? yes
Instead of violation of DDD principles, as I understand it? No

I would argue that. at least today's version of this project. Suggests that the community agrees that creating more DTO objects just to save your data is a pattern that we should generally try to avoid.

I'm curious what other. followers of this project think of this?
Please feel free to correct me as I'm not learning and growing also.

[ardalis]

I agree with @lukehammer.

Why do we directly leverage the domain model classes from Core via EF DbContexts in Infrastructure? Because we can, with no ill effects! EF Code First is a feature they added many years ago specifically because developers wanted this capability. Prior to that, one would have a DbContext which had its own models, and you would need to map them manually to your domain model, and it was just one more set of mappings that didn't really add any value.

Now, if you don't own your database, which means you don't have a DDD bounded context, then you may find value in having a separate persistence model in your infrastructure code. Why? Because you want your domain model to be able to evolve as you learn more about the business, but you're forced to use an existing database schema/model. So this is a scenario in which it might make sense to have separate persistence and domain models. But it's only because it is not the ideal case. It's a workaround.

If you're following DDD, then within your bounded context you have a ubiquitous language which dictates how your model is organized and named, and that language should flow through to your persistence model. You decide to change Customer to Account? Great, do that and make sure you change it everywhere in the database schema as well! This is of course much easier to do if you don't have a separate persistence model - there are fewer places in which you must make such a change.

HTH.
Steve

[lukehammer]

@ardalis
Thank you it's an honor to be agreed with you. Big Fan! This is the highlight of my week.😄

I should have thought of this because it did this also. 🧐 I had a requirement that forced me to use an older database with limits on table column names, which created some stupid names for items that eventually became code.

The first thing I did after joining the team was to separate the database actions from the rest of the code. This was met with some objections at first. But shortly after, people started getting behind the idea of CreditCard.ExperationDate being better than CCEXDATE. In short, I isolated the bad name conversion to the database part of the infrastructure project.

before this name would have been leaked into the business logic and even sometimes to the views.
So there is a use case. but like @ardalis said above this was a compromise because of old/bad design limitations.

[nabeelfarooqui98]

Thanks for the information @lukehammer @ardalis

Luckily I'm working on a greenfield project and we do own the database as well. So it's not like we're trying to add an app on top of an existing database.

The reason I even thought about separate infrastructure entities was because in our domain we have several properties of a class which we were planning to store as a single column in the database (as a json perhaps).

It's very likely we will add more properties to that class later and we didn't want to have to run migrations of the database. Any property which didn't exist in the db JSON would be null.

I will see if we really need to do it this way. Because from what both of you have said (and everywhere else I've looked) it seems like using domain objects in the infrastructure is what everyone is doing.

Thanks!

[ardalis]

I don't recommend the json approach for most things. It will be slower but more importantly you'll have to deal with versioning it later. In my experience the pain of dealing with the flexible column will outweigh the pain of migrations.

If you're storing something and you never need to worry about what it is (it's json from some other system and you're going to send it back as is for instance) then fine but otherwise be very careful and expect pain if and when things evolve.