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.

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.

// 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.

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

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

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.

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.

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.

“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.

Tapio

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?