Should the domain model be completely isolated?

[w00519772]

Thanks again for developing this app. I am enjoying learning more about it.

Domain Driven Design states that you should have a domain model, which reflects the ubiquitous language used by the domain experts. I see that you are using EF Core and have the ORM mapped to the Domain model in the Ordering microservice. I have two questions:

1. How would you deal with a many to many relationship? I believe you have to create a join Domain entity with EF Core as described here: Discussion on many-to-Many relationships (without CLR class for join table) dotnet/efcore#1368. Is that how you would do it? Some argue that this would "pollute" the domain model. It could also mean that you have class names that do not reflect the ubiquitous language used in the domain.

2. Would you ever have a completely isolated domain model i.e. a domain model that is not mapped to a relational database? I believe a separate domain model would make change tracking harder.

[CESARDELATORRE]

The Domain Model should be isolated meaning that other parts of the application depend on the model, but the model classes must not depend on anything but themselves, they must be POCO classes. Entity Framework complies with that since your entities are just POCO classes and the mapping between the entity classes and the database is performed under the covers without contaminating the Domain Entity classes. In the entity classes you have only your code.

• Many to many relationships? - I see no issues on that, within the same Aggregate you can establish 1:1, 1:Many or Many:Many relationships.
  However, between different Aggregates, you should not have explicit relationships using Entity Framework. If there are relations between different aggregates should be based just on the IDs/Keys and Foreign Keys, but without explicit relationships in EF, meaning no navigation between Aggregates.
  In nay case Aggregates should be uses for transactions, most of all.
  You can have a CQRS approach and segregate the queries from all the Domain Model. You can use the Domain Model nd all the DDD constraints only for the transactions/updates. For queries you can have separated code since queries don't impact the data and might be more flexible for queries to use a different data model based on the same physical tables where you can use any kind of join, etc.

See how we implemented that approach in the Ordering microservice. Queries are segregated from the DDD/Aggregates model by using a simplified CQRS approach against the same database. It is explained in the book, as well.

2. Again, isolated model doesn't mean that it cannot be mapped to a relational database. It can be mapped to a relational database by using Entity Framework or any other ORM as long as the Entity Model classes do not depend on any library or infrastructure. That's what means "isolated model".

3. About change tracking, take into account that the Domain Entities are used only in the "server side", so change tracking (connected EF DbContext managing all the changes) is only needed while running the transactions. When you return data to the client side, you return DTOs in the form that the client app needs it better. You must not send the Domain Entities to the client side.

$. For transactions, you start from the client side sending data related to the transactions in the form of a Command, which is a simple class, like a DTO, but sending the data related to the business operation/Command. That will start the transaction with the Domain Aggreegates.

[w00519772]

@CESARDELATORRE

Thank you. I think I agree with your definition of isolation with regards to point two.

With regards to point one; say I had the classes below (which I took from here: https://www.learnentityframeworkcore.com/configuration/many-to-many-relationship-configuration):

public class Book
{
    public int BookId { get; set; }
    public string Title { get; set; }
    public Author Author { get; set; }
    public ICollection<BookCategory> BookCategories { get; set; }
} 

public class Category
{
    public int CategoryId { get; set; }
    public string CategoryName { get; set; }
    public ICollection<BookCategory> BookCategories { get; set; }
}

public class BookCategory
{
    public int BookId { get; set; }
    public Book Book { get; set; }
    public int CategoryId { get; set; }
    public Category Category { get; set; }
}

It does not seem right adding BookCategories to Books and BookCategories to Categories. In my mind Books should be added to Categories and Categories should be added to Books.

I don't believe eshopcontainers has an many to many relationships. However, if it did then would this make you choose another ORM or am I overthinking this?

[gojanpaolo]

Defining the join entity (i.e. BookCategories) on Book and Category seems fine to me. That's exactly how the models will be related and you're just explicitly defining it. Of course it is nice/convenient to not define the join entity yourself. But keep in mind that when EF Core can handle many-to-many relationships without an explicit join entity, EF Core will still create that join entity implicitly.

If you want to hide the join entity on the domain classes consumers, you can follow this blog post from Arthur Vickers.

[mvelosop]

Hi @w00519772,

I think perhaps a little bit of history might help to better grasp what "Domain Model isolation" means.

Back in the day, with EF 2 (I mean EF 2, NOT EF Core 2) your entity models had to be worked as partial classes, where the other partial half of the class where properties that dealt with framework related task, so your domain model classes had to handle a bunch of properties (I don't remember if there where methods too) that were framework related and had nothing to do with your domain.

That's why I think the emphasis on POCOs would be better understood when compared to the "Frankenstein" models that had to be used some time ago (~8 years)

Reganding the UI - Domain model separation, it has always helped me to make a difference between ViewModels and Domain Models.

View Models are models for the view, they are just DTOs I create to make my life easier when handling the UI, to both display info and getting user input.

So I might have two different view models that map to the same set of domain models, just to make easier for the client view.

In UI discussions, specially some time ago, it wasn't clear that the "M" in MVC is really a ViewModel.

Hope this helps.

[mvelosop]

Closing this issue now as it seems to be solved, feel free to comment though, will reopen if needed.