Image may be NSFW.
Clik here to view.
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