DDD & Many to Many Object Relational Mapping

Saturday, January 24th, 2009.

many to many The ability to map entity relationships is broadly supported by many O/RM tools. For some reason, though, many developers run into issues when trying to map a many-to-many relationship between entities. Although much has already been written about the technological aspects of it, I thought I’d take more of an architectural / DDD perspective on it here.

Value Objects Don’t Count

While the canonical example presented is Customer -> Address, and has a good treatment here for nHibernate, it isn’t architecturally representative.

Addresses are value objects. What this means is that if we have to instance of the Address class, and they both have the same business data, they are semantically equivalent. Customers, on the other had, are not value objects – they’re entities. If we have two customers with the same business data (both of them called Bob Smith), that does not mean they are semantically equivalent – they are not the same person.

All Entities

Therefore, for our purposes here we’ll use something different. Say we have an entity called Job which is something that a company wants to hire for. It has a title, description, skill level, and a bunch of other data. Say we also have another entity called Job Board which is where the company posts jobs so that applicants can see them, like Monster.com. A job board has a name, description, web site, referral fee, and a bunch of other data.

A job can be posted to multiple job boards. And a job board can have multiple jobs posted. A regular many to many relationship. At this point, we’re not even going to complicate the association.

This is simply represented in the DB with an association table containing two columns for each of the entity tables’ ids.

In the domain model, developers can also represent this with the Job class containing a list of JobBoard instances, and the JobBoard class containing a list of jobs.

It’s intuitive. Simple. Easy to implement. And wrong.

In order to make intelligent DDD choices, we’re going to first take what may seem to be a tangential course, but I assure you that your aggregate roots depend on it.

Moving forward with our example

Let’s say the user picks a job, and then ticks off the job boards where they want the job posted, and clicks submit.

For simplicity’s sake, at this point, let’s ignore the communication with the actual job sites, assuming that if we can get the association into the DB, magic will happen later causing the job to appear on all the sites.

Our well-intentioned developer takes the job ID, and all the job board IDs, opens a transaction, gets the job object, gets the job board objects, adds all the job board objects to the job, and commits, as follows:

   1:          public void PostJobToBoards(Guid jobId, params Guid[] boardIds)

   2:          {

   3:              using (ISession s = this.SessionFactory.OpenSession())

   4:              using (ITransaction tx = s.BeginTransaction())

   5:              {

   6:                  var job = s.Get<Job>(jobId);

   7:                  var boards = new List<JobBoard>();

8:

   9:                  foreach(Guid id in boardIds)

  10:                      boards.Add(s.Get<JobBoard>(id));

11:

  12:                  job.PostTo(boards);

13:

  14:                  tx.Commit();

  15:              }

  16:          }

In this code, Job is our aggregate root. You can see that is the case since Job is the entry point that the service layer code uses to interact with the domain model. Soon we’ll see why this is wrong.

** Notice that in this service layer code, our well-intentioned developer is following the rule that while you can get as many objects as you like, you are only allowed one method call on one domain object. The code called in line 12 is what you’d pretty much expect:

   1:          public void PostTo(IList<JobBoard> boards)

   2:          {

   3:              foreach(JobBoard jb in boards)

   4:              {

   5:                  this.JobBoards.Add(jb);

   6:                  jb.Jobs.Add(this);

   7:              }

   8:          }

Only that as we were committing, someone deleted one of the job boards just then. Or that someone updated the job board causing a concurrency conflict. Or anything that would cause one single association to not be created.

That would cause the whole transaction to fail and all changes to roll back.

Rightly so, thinks our well-intentioned developer.

But users don’t think like well-intentioned developers.

Partial Failures

If I were to go to the grocery store with the list my wife gave me, finding that they’re out of hazelnuts (the last item on the list), would NOT buy all the other groceries and go home empty handed, what do you think would happen?

Right. That’s how users look at us developers. Before running off and writing a bunch of code, we need to understand the business semantics of users actions, including asking about partial failures.

The list isn’t a unit of work that needs to succeed or rollback atomically. It’s actually many units of work. I mean, I wouldn’t want my wife to send me to the store 10 times to buy 10 items, so the list is really just a kind of user shortcut. Therefore, in the job board scenario, each job to job board connection is its own transaction.

This is more common than you might think.

Once you go looking for cases where the domain is forgiving of partial failures, you may start seeing more and more of them.

Aggregate Roots

In the original transaction where we tried to connect many job boards to a single job, we saw that the single job is the aggregate root. However, once we have multiple transactions, each connecting one job and one job board, the job board is just as likely an aggregate root as the job.

We can do jobBoard.Post(job); or job.PostTo(jobBoard);

But we need just a bit more analysis to come to the right decision.

While we could just leave the bi-directional/circular dependency between them, it would be preferable if we could make it uni-directional instead. To do that, we need to understand their relationship:

If there was no such thing as “job”, would there be meaning to “job board” ? Probably not.

If there was no such thing as “job board”, would there be meaning to “job” ? Probably. Yes. Our company can handle the hiring process of a job regardless of whether the candidate came in through Monster.com or not.

From this we understand that the uni-directional relationship can be modelled as one-to-many from job board to job. The Job class would no longer have a collection of Job Board objects. In fact, it could even be in an assembly separate from Job Board and not reference Job Board in any way. Job Board, on the other hand, would still have a collection of Job objects.

Going back to the code above we see that the right choice is jobBoard.Post(job);

Job Board is the aggregate root in this case. Also, the many-to-many mapping has now dissolved, leaving behind a single one-to-many mapping.

Let that sink in a second.

But Wait…

While the GUI showing which jobs are posted on a given job board are well served by the above decision (simply traversing the object graph from Job Board to its collection of Jobs), that’s not the whole story. Another GUI needs to show administrative users which Job Boards a given Job has been posted to. Since we no longer have the domain-level connection, we can’t traverse myJob.JobBoards.

Our only option is to perform a query. That’s not so bad, but not as pretty as object traversal.

The real benefit is in chopping apart the Gordian M-to-N mapping knot and getting a cleaner, more well factored domain model.

That gives us much greater leverage for bigger, system-level decomposition.

We’re now all set to move up to a pub/sub solution between these aggregate roots, effectively upgrading them to Bounded Contexts. From there, we can move to full-blown internet-scale caching with REST for extra scalability on showing a job board with all its jobs.

In Closing

We often look at many-to-many relationships just like any other relationship. And from a purely technical perspective, we’re not wrong. However, the business reality around these relationships is often very different – forgiving of partial failures, to the point of actually requiring them.

Since the business folks who provide us with requirements rarely think of failure scenarios, they don’t specify that “between these two entities here, I don’t want transactional atomicity” (rolling our technical eyes – the idiots [sarcasm, just to make sure you don’t misread me]).

Yet, if we were to spell out what the system will do under failure conditions when transactionally atomic, those same business folks will be rolling our eyes back to us.

What I’ve found surprises some DDD practitioners is how critical this issue really is to arriving at the correct aggregate roots and bounded contexts.

It’s also simple, and practical, so you won’t be offending the YAGNI police.

Related Content

From CRUD to Domain-Driven Fluency

[Podcast] Domain Models, SOA, and The Single Version of the Truth

If you liked this article, you might also like articles in these categories:

If you've got a minute, you might enjoy taking a look at some of my best articles.
I've gone through the hundreds of articles I've written over the past 6 years and put together a list of the best ones as ranked by my 5000+ readers.
You won't be disappointed.

If you'd like to get new articles sent to you when they're published, it's easy and free.
Subscribe right here.

Follow me on Twitter @UdiDahan.

Something on your mind? Got a question? I'd be thrilled to hear it.
Leave a comment below or email me, whatever works for you.

34 Comments

Andy Palmer Says:
January 24th, 2009 at 2:28 pm
Another fantastic blog post, thanks Udi.

Ayende Rahien Says:
January 24th, 2009 at 2:34 pm
If I understand you correctly, Job Board is the aggregated root. But Job doesn’t know about Job Board.

The problem with that is that now you have Job taking part in several aggregated roots. Doesn’t this defeat the whole purpose of aggregated roots?

Tapio Kulmala Says:
January 25th, 2009 at 3:45 am
If the Job entity has a meaning outside of the context of the Job Board, it’s not part of the Job Board aggregate. A Job Board will have a reference to it but it does not make it part of the aggregate.

Tapio

New and Notable 283 : Sam Gentile's Blog (if (DeveloperTask == Communication && OS == Windows) Says:
January 25th, 2009 at 11:24 am
[…] Udi on DDD & Many to Many Object Relational Mapping […]

Reflective Perspective - Chris Alcock » The Morning Brew #272 Says:
January 26th, 2009 at 2:07 am
[…] DDD & Many to Many Object Relational Mapping – Udi Dahan takes a look at the complexities of Many To Many Mappings using ORM technology from an architectural / DDD standpoint. […]

BizTalk Linkflood, January 26, 2009 « ADA ICT Devsquad’s Blog Says:
January 26th, 2009 at 3:23 am
[…] DDD & Many to Many Object Relational Mapping […]

Sean Chambers Says:
January 26th, 2009 at 6:59 am
Excellent example, but you seem to have removed one of the requirements that you originally stated to get it to fit into your example:

“A job can be posted to multiple job boards. And a job board can have multiple jobs posted.”

If thats the case, how can you still achieve that with a Job only belonging to one job board? It seems like your example works, but violates the requirements that were originally stated.

udidahan Says:
January 26th, 2009 at 2:18 pm
Ayende, Tapio, Sean,

For me, “aggregate root” is the DDD term for “only calling one method on one object in your service layer”. In other words, it’s use case specific, and not an inherent structural property of the domain model.

Hope that helps.

Michael Hart Says:
January 26th, 2009 at 5:32 pm
@Sean – I assume that Udi meant the shift from many-to-many to one-to-many only happened in the mapping itself (ie, the Job class no longer has a property relating to JobBoard at all – whether singular or plural). A many-to-many is really like two one-to-manys and in this case one of those has been hidden at the object level. The database tables could still be mapped in the original many-to-many fashion.

Marc Brooks Says:
January 26th, 2009 at 11:10 pm
So, can a job “be” until it’s been posted to a board? Is a board useful (in an non-admin sense / more than a lookup table) until some job is posted to it?

Perhaps the REAL root is the Job Posting, which is queried for matching jobs or boards. I’ve found that most output/report pages (which is what most software is about–getting the data out in useful projections) is presented in some form of list, so defining the aggregate root “property” as a collection of JobBoardPosting is the clearest approach to me.

Andy Hitchman Says:
January 27th, 2009 at 3:52 pm
I’d suggest that Job is probably more important to the users managing recruitment. The domain around Jobs is likely much richer than this example has so far explored. This would lead me to infer that Job is the aggregate root.

If you wish to abstract the association of Job Board to Job, then perhaps a service to control the publication of Jobs to Job Boards is more appropriate.

udidahan Says:
January 29th, 2009 at 4:57 pm
Marc, Andy,

You’re both right.
In one bounded context, Job is an aggregate root, in another, it’s Job Board.

Nuno Lopes Says:
January 30th, 2009 at 9:44 am
I liked the mention of partial failures and its often forgotten in batch business transactions scenarios. Nevertheless I fail to understand how that particular business requirement actually mandates who the root should be.

Whoever read Streamlined Object Modelling (wich I strongly advise) basically understand that the collaboration director between two objects should have the business function (your aggregate root), the other is optional. Now the collaboration director depends on the complexitiy of business rules within that collaboration.

* Does the JobBoard imposes any constraints over inlisting Job Vancacies?

* Does the Job (or a Job with status vacant) imposes any constraints over advertising on specific JobBoards (one would not publish a Job Vacancy of Finantial Director of a top 5 company on an IT Job Boards)?

In a situation like this Many-To-Many usually the collaboration director should be the one who carries the most complex business constraints.

I’m always very, very suspicious about Many to Many relationships. In most cases it means that the domain is not well understood as roles are not in place (Modeling in Color & Streamlined Object Modeling).

Let me explain.

You are absolutely right, we should not couple what does not need to be coupled. That is, if the Job class represents mostely anything else then a Job Vacancy ready to be advertised then a new Class JobVacancyPost is needed. This JobVacancyPost is the Role of a Job within this collaboration (read Modeling in Color or serch for the Domain Neutral Componentt) modelled as a separate class, not even part of the core HR domain of a Company (where Job and JobSpecification are modeled).

Job{1:N} JobVacancyPost (Role+MI) {N:1} JobBoard

JobVacancyPost is a first order object in the domain (as it workds as a Role of Job and a Post in a Job Board) so it does not hurt anyone to state that it should be located by a Repository.

“That’s not so bad, but not as pretty as object traversal.”

There is no such thing IMHO. if the natural way would be through object transversal means that the domain is not well understood by the developer (aka as not well mapped).

In other words we can most of the times reduce a M:N relationship to either {1:N} or to {1:N:1} only if the domain allows from pure DDD (othwerwise Domain Drive = Model Driven IMHO), nothing else nothing more. If not more sooner then later you will face problems, hacks and turns.

Execuse my ramblings in my first post and I’m learning.

Nuno Lopes
PS: If people don’t know what DNC is look for this http://www.step-10.com/SoftwareDesign/ModellingInColour/TheDomainNeutralComponent.htmlor this http://www.petercoad.com/download/bookpdfs/jmcuch01.pdf

Nuno Lopes Says:
January 30th, 2009 at 10:13 am
I failed to mention interactions my explanation so here it is on the service layer:

// begin transaction
….
JobVacancyPost aJVP = new JobVancncyPost(Job); // usually this is how roles are created
aJVP.Send(aJobBoard)
tx.Commit();
…
// end transaction

IMHO there is no such thing as partial failures. If there is business rule stating that all Job Vacancies should be advertised or not at all, then most probabably a JobVancancySheet is in order. If this the case we would have:

….
try catch()
{
tx.begin()
var job = s.Get(jobId);
JobVacancySheet aJVS = new JobVacancySheet();
foreach(Guid id in boardIds)
{
aJVS.Add(aJob, session.Get(id));
}
JobVacancySheet.Send();
tx.Commit()
}
catch {Exception ex)
{
// depending on the expcetion it would postpone sending to later (say external services are down) or fail completely advising the user to correct the sheet.
}

Nuno Lopes
PS: This are my personal views, in no way whatsover they are absolute.

Dew Drop - February 1, 2009 | Alvin Ashcraft's Morning Dew Says:
February 1st, 2009 at 2:59 pm
[…] DDD & Many to Many Object Relational Mapping and ALT.NET DDD Podcast (Udi Dahan) […]

udidahan Says:
February 3rd, 2009 at 3:44 am
Nuno,

It’s not that the partial failures dictate which object is the aggregate root, but they indicate that the intuitive answer isn’t necessarily correct.

> IMHO there is no such thing as partial failures

Well, that’s a question that should be put to the business. If we include in the discussion the time within which the system will be consistent one way or the other (say, 1 minute), you may find that partial failures and eventual consistency are quite acceptable.

Also, it’s usually easier to scale a system built around partial failures than one founded in 100% consistency.

And thanks for sharing your personal views – it’s really valuable seeing other perspectives.

Ramin Says:
March 6th, 2009 at 3:48 am
If the board not only posts jobs but other information, would you then have 3 aggregates roots: job, info-board and info-board-job-posting? Would the info-board-job-posting aggregate root then subscribe to the two others in a publish/subscribe solution? How would that be best modeled?

udidahan Says:
March 9th, 2009 at 4:04 pm
Ramin,

I’d need a fair bit more information about the other use cases and relevant data to say anything about the scenario you’re alluding to.

Part 9: NHibernate transactions « BASICly everything Says:
September 8th, 2009 at 5:53 am
[…] Partial failures can be good. The programmer in all of us sees that and screams atomicity. Transactions should be all-or-nothing. Anything less is just wrong. Right? In real life, there are instances where we allow, and even prefer partial failures of business transactions. Udi gives us a great example. Would you leave the grocery store empty handed simply because they were out of one item on your list? Probably not. When you’re gathering requirements, be sure to ask questions about the proper way to fail. “Roll it all back” isn’t the only option. […]

Part 9: NHibernate transactions - NHibernate blog - NHibernate Forge Says:
September 8th, 2009 at 5:58 am
[…] Partial failures can be good. The programmer in all of us sees that and screams atomicity. Transactions should be all-or-nothing. Anything less is just wrong. Right? In real life, there are instances where we allow, and even prefer partial failures of business transactions. Udi gives us a great example. Would you leave the grocery store empty handed simply because they were out of one item on your list? Probably not. When you’re gathering requirements, be sure to ask questions about the proper way to fail. “Roll it all back” isn’t the only option. […]

Elegant Code » Tips for ORM Data Access Says:
November 12th, 2009 at 3:22 pm
[…] Learn how to identify the right aggregate […]

Christian Says:
February 8th, 2010 at 4:53 am
Just a stupid question. Why is an address a value object???

p47l4f0n [3D noob] Says:
September 27th, 2010 at 4:22 am
Hello, many thanks to you for this very valuable post and also to others for their comments.
I’d know if this coul’d be the solution for that problem:
– there are 2 really independent entities.
– there are 4 points of view at the relationship between them
1) Job is independent, doesn’t know about any JobBoard AND
JobBoard is independent, doesn’t know about any Job (it’s just a PostBoard) [potentional Employee’s view]
2) Job knows about JobBoard, but “PostBoard” doesn’t know about any Jobs [HR manager’s view]
3) Job doesn’t know, that it’s been posted anywhere, but JobBoard knows Jobs [JobBoard manager’s view]
4) Job and JobBoard know them both. [Programmers view]

If we are implementing just one point of view (is it bounded context?), there is one or two agreggate root(s)
If we are implementing more than one PoV, there are more agregate roots up to four. Here I feel that the max value of combinations could be get by some kind of math formula…
Could this simply help us to check quickly, if we’ve been right for one aggregate root, if we expected two PoV?

udidahan Says:
September 28th, 2010 at 12:20 pm
3D noob,

I’m not exactly sure how to respond to you. While multiple users may want to view the same information slightly differently, that doesn’t always translate to different bounded contexts – often its just different query screens. When working with CQRS, these queries aren’t served off of the domain model so you can do almost anything you like there.

chandra Says:
February 15th, 2011 at 5:12 am
You have said that, query should be used for fetching data from job’s aggregate.

But is that defeat ddd perspective. Why query ?

Do we avoid m to m always and convert that in to 1 to m ?

udidahan Says:
February 15th, 2011 at 11:32 pm
Chandra,

I believe that I said that we would use a separate query to get the job boards by job ID, rather than navigating the collection. That doesn’t defeat the purpose of DDD. I suggest reading up on some of my CQRS material to understand more about how queries should be handled by different objects than commands.

Didier Says:
March 13th, 2014 at 1:05 am
Are you suggesting that we should never have a many-to-many relationship in our domain model, because they make the mapping to a database cumbersome and difficult?

And then are you justifying this change in your domain model based on your persistence system by implying that it was a bad modeling in the first place?

Or are you saying some of those many-to-many relationships would be better modeled in a one-to-many, but it’s ok to still have some many-to-many if that’s what makes more sense to the model?

udidahan Says:
March 13th, 2014 at 4:30 pm
Didier,

In many of my later blog posts I talk about the concept of Bounded Contexts (or SOA Services) which encapsulate strong business responsibilities.

It’s been my experience that since entities on either side of a many-to-many relationship have the ability to exist independently of each other, the often belong in different Bounded Contexts.

As such, since a domain model sits entirely inside a Bounded Context, we would not expect to see many-to-many relationships there.

adi Says:
August 29th, 2014 at 2:51 pm
I have relation like this:
Vacancy – {1:N} – Assignment – {N:1} – Candidate

Assignment has property “IsPrimary”

And business rule:
Candidate can be primary only on 1 vacancy at the same time
and vacancy can has only 1 primary candidate.

Then I need to check these conditions before I can set IsPrimary property:
1. For candidate: assignments.Any(x => x.IsPrimary) (IsPrimaryCandidate)
2. For vacancy: assignments.Any(x => x.IsPrimary) (HasPrimaryCandidate)

When I try to unit test that behavior of the domain model

[TestMethod]
public void SetPrimaryCandidateOnVacancy()
{
var candidate = new Candidate(“Some Candidate”);
var vacancy = new Vacancy(“Some Vacancy”);

vacancy.AddAssignment(candidate);
vacancy.MakeAssignmentPrimary(candidate);

Assert.IsTrue(vacancy.HasPrimaryCandidate);
Assert.IsTrue(candidate.IsPrimaryCandidate);
}

It will fail.

To fix it I need to populate assignments on both candidate and vacancy,
inside vacancy.AddAssignment method I need to call candidate.AddAssignment(assignment).

But if I will try to do integration test and perform
AddAssignment and MakeAssignmentPrimary in different sessions (NHibernate)
then I don’t need to call candidate.AddAssignment(assignment)
it will be persisted using cascade configured in mapping.

I don’t like adding another method.

What you can suggest in such case?

Thank You.

udidahan Says:
August 31st, 2014 at 11:45 am
Adi,

I suggest creating bigger methods that encapsulate those sorts of behaviors on your objects.

Additionally, if the rule for “at most one primary candidate” is stable, you should model it as such. Meaning having a PrimaryCandidate property on the Vacancy, or having a PrimaryVacancy property on the Candidate – keeping that separate from the collection.

In any case, I think that the rule as specified probably won’t hold up longer-term in the real world. The world is much too messy.

adi Says:
September 1st, 2014 at 12:17 pm
Thank You for reply Udi.

But creating PrimaryCandidate property wouldn’t help.
I need also to create PrimaryVacancy on Candidate.

It will be same situations but without collections.

On vacancy:
public virtual void MakeCandidatePrimary(Candidate candidate)
{
if (IsClosed)
throw new InvalidOperationException(“Vacancy is closed.”);

if (primaryCandidate != null)
throw new InvalidOperationException(“Vacancy already has primary candidate.”);

// Here is the problem when I try to test pure domain model without ORM cascade
if (candidate.PrimaryVacancy != null)
throw new InvalidOperationException(“Candidate is already primary on vacancy.”);

primaryCandidate = candidate;

// This is the fix to allow testing domain model “in-memory”, but I it looks wrong.
candidate.MakePrimaryOnVacancy(this);
}

On candidate:
public virtual void MakePrimaryOnVacancy(Vacancy vacancy)
{
if (vacancy.IsClosed)
throw new InvalidOperationException(“Vacancy is closed.”);

if (vacancy.PrimaryCandidate != null)
throw new InvalidOperationException(“Vacancy already has primary candidate.”);

if (primaryVacancy != null)
throw new InvalidOperationException(“Candidate is already primary on vacancy.”);

primaryVacancy = vacancy;
}

I can’t figure out how can I avoid this bidirectional relation,
because I need to validate business rule that candidate is not primary on some vacancy.
Same situation if I try to do it vice-versa, I need to validate vacancy if it contains some primary candidate.

adi Says:
September 3rd, 2014 at 2:34 pm
I ended up with the following solution:

On Vacancy:
public virtual void AddCandidate(Candidate candidate)
{
if (IsClosed)
… “Cannot add assignment to closed vacancy.”

if (assignments.Any(x => x.Candidate == candidate))
… “Candidate is already assigned to this vacancy.”

var assignment = new VacancyAssignment(this, candidate);
assignments.Add(assignment);

candidate.AssignVacancy(this);
}

On Candidate:
protected internal virtual void AssignVacancy(Vacancy vacancy)
{
var assignment = vacancy.Assignments.FirstOrDefault(x => x.Candidate == this);
if (assignment != null)
{
assignments.Add(assignment);
}
else
{
vacancy.AddCandidate(this);
}
}

Now AssignVacancy is hidden for outside of domain assembly.
Even if some one inside the domain will try to add assignment
from Candidate side then AssignVacancy can handle this situation.

And now I can use vacancy.HasPrimaryCandidate and candidate.IsPrimaryCandidate
in test without ORM.

Israel Pereira Says:
September 12th, 2014 at 3:41 pm
Hi Sir, first of all Thanks for the article.
I am on this situation
“Another GUI needs to show administrative users which Job Boards a given Job has been posted to. Since we no longer have the domain-level connection, we can’t traverse myJob.JobBoards.”

And I also post the job to Job Boards on this GUI.
Is it nice or is bad idea ? where will be the method PostJobToBoards?

Where will be the query method to get the Job Boards ? in the Job Boards service or Job Service ?

Thank you

udidahan Says:
September 13th, 2014 at 5:20 pm
Israel,

I suggest performing queries without going through the same domain objects. You can put this query on a separate API.

With regards to posting a job to multiple boards, I’d recommend sending multiple messages over a queue where each message is posting a job to a single board.