5

In DDD, a guideline states that domain models are not supposed to have something to do with persistence. It means that different domain models may rely on the same tables. Meanwhile, it seems that this goal is pretty difficult to reach, because of technical limitations in ORMs in transforming models (I suppose ?). Is there a way, with actual ORMs, to create very specific domain models that rely on the same tables in database, and to prevent the disappointing [1:1] mapping between entities and tables we have in 99.99% of DDD implementations ? Do these technical limitations (?) make the guideline obsolete ?

Thanks,

Rénald
  • 1,412
  • 12
  • 29
  • 2
    "It means that different domain models may rely on the same tables"... that statement isin't clear? What do you mean? – plalx Apr 16 '15 at 01:19
  • Do you need to map one entity to multiple tables or multiple entities to one table ? – guillaume31 Apr 16 '15 at 15:35
  • I need to map multiple entities to the same tables, but in different ways. Pick-up some data in the some tables and map it to different entities, to create domains (example : one for fraud detection, one for administrative functions, etc...). If I am not able to do that, it brings the point of duplicating data. I have a real problem with duplicating data. I know it sometimes make sense, probably I will post a question about that... – Rénald Apr 17 '15 at 06:26
  • well, sometimes you even have to map one entity to two different databases, like redis and mysql. Unfortunately entity frameworks most of the time do not let us do that, so you can't base on them. – Rafał Łużyński Apr 17 '15 at 09:52
  • @Rénald this way is actually possible with most ORM's. What makes you think it isn't ? Have you tried ? – guillaume31 Apr 20 '15 at 09:08
  • @RafałŁużyński I think the question is not about that. Plus, what prevents you from defining multiple code-first fluent DBContexts pointing to different (EF-supported) DB's ? – guillaume31 Apr 20 '15 at 09:42

4 Answers4

3

The "disappointing [1:1] mapping" between entities and tables might disappoint you in two ways -- not being able to populate an entity from multiple tables, and not being able to populate multiple entities from the same table.

As it seems you're more interested in the latter, it's possible with most ORM's, even if only by defining different mappings for one table in separate mapping "instances" of the ORM. A solution for Entity Framework is described here and here.

Community
  • 1
  • 1
guillaume31
  • 13,738
  • 1
  • 32
  • 51
1

I guess the answer depends on just how different your domain models are from your database tables. Sometimes you may not be able to achieve DDD persistence using ORMs alone. This should not deter you or cause you to design your domain models around your database. This is also the very reason DDD has the concept of a repository interface, because the task of peristing your models may be very complex.

The guideline is no more obsolete now than when it was first written. ORMs may or may not be compatible with this guideline, however it doesn't mean it's not achievable using other methods.

I do agree with your assessment that most DDD models are a 1:1 mirror of the database. The short answer is that persistence is not always easy, but never impossible.

Tyler Day
  • 1,690
  • 12
  • 12
1

If you use Java, you can use MyBatis which follows the Data Mapper pattern to achieve that.

chanjarster
  • 506
  • 3
  • 17
  • Very interesting. It seems there is a port of MyBatis for .NET. I will check that as soon as possible. Thanks for your contribution. – Rénald Apr 17 '15 at 06:10
0

One the key ideas in DDD is bounded context that contains several things such as:

  • Ubiquitous Language
  • Aggregate Roots
  • Entities
  • Domain Services
  • Domain Events
  • Database Tables

There are two possible situations that can arise with DDD depending on weather the project is green field or brown filed.

  • In a green field project with where everything is done with DDD there will be clear sub domains, clear bounded contexts, you will have database tables that are considered to be within the bounded context and you will get 1 : 1 mapping between tables an entities kind of what you with JPA / Hibernate ... etc.
  • In a brown field project with an existing database that can not be changed one database could support multiple bounded contexts and it is possible that some tables might have different parts of their columns mapped to different domain entities in different bounded contexts.

There is a good discussion of this question on page 66 to 68 in the book "Implementing Domain Driven Design" by Vaughn Vernon.

Joe
  • 47
  • 8
ams
  • 60,316
  • 68
  • 200
  • 288