Comments on: Life inside an Aggregate Root, part 1

By: Ali Çevik

Ali Çevik — Thu, 19 Apr 2012 19:41:10 +0000

How about this: allow adding a Skill only through a call to the TrainingProgramme.

trainingProgramme.AddSkill(skillGroupName, skill)

This way you could make the validation before adding the Skill to the SkillGroup yet without a circular dependency.

By: Thomas Han

Thomas Han — Wed, 24 Aug 2011 21:44:21 +0000

You’ve stated that
Entities can only hold references to aggregate roots, not entities or value objects within.

Why can’t the entities hold a reference to VO???

Entities can’t hold reference to other entities due to aggregate boundary stating is can’t hold reference other entities but through the aggregate root but there is no reason entities can’t hold a reference to VO.

By: Fred Wang

Fred Wang — Tue, 10 Aug 2010 08:46:06 +0000

Hi Richard,

In my opinion,there are two kinds work of aggregate root:
1.as a container(or lifemanagement) ,it is the root,we have a relation from the root to the leaves .It is a unidirectional relationship.
2.for validation task(or some thing similar),just as your example.So the leaves need a reference to the root.It is a bidirectional relationship.

But , I think the bidirectional is very hard to maintain, if we don’t need the validation function,do we need a bidirectional?
Another question is ,if I have a deep graph,how to set the reference to the root and mantain the bidirectional relationship by nhibernate?

Cheers,
Fred Wang

By: Jaime Metcher

Jaime Metcher — Thu, 28 Jan 2010 00:54:33 +0000

I don’t really have a problem with the backreference from SkillGroup to TrainingProgramme, but having a method TrainingProgramme.addSkill(skillGroup,skill) that does the uniqueness check before calling skillGroup.add(skill) seems to me to be putting the responsibility where it belongs. The requirement for whole of programme skill uniqueness is part of the specification of TrainingProgramme, and yet it’s being implemented by SkillGroup. To put it another way, looking at the code of TrainingProgramme would not tell you that requirement existed.

By: Reflective Perspective - Chris Alcock » The Morning Brew #454

Reflective Perspective - Chris Alcock » The Morning Brew #454 — Wed, 14 Oct 2009 07:47:42 +0000

[...] Life inside an Aggregate Root, part 1 – Richard Dingwall explores one of the key Domain Driven Design tenants, the ‘aggregate root’ in this two part article discussing the key rules about how they should behave [...]

By: Richard Dingwall » Life inside an Aggregate Root, part 2

Richard Dingwall » Life inside an Aggregate Root, part 2 — Tue, 13 Oct 2009 20:13:23 +0000

[...] This is the second half of a two-part article. Read the first half here: Life inside an Aggregate Root, part 1. [...]

By: Richard

Richard — Mon, 12 Oct 2009 23:58:40 +0000

Kevin: good question – I inject the aggregate root into the entity when it is constructed i.e., when you create a SkillGroup, you specify which TrainingProgramme it belongs to (see example). If you’re using NHibernate, the TrainingProgramme->SkillGroup association is inverse.

Part 2 will be about making the TrainingProgramme responsible for constructing child SkillGroups :)

By: Kevin Berridge

Kevin Berridge — Mon, 12 Oct 2009 23:31:16 +0000

Not sure if you’re planning on covering this in a future post, but I’m curious. If you were using NHibernate (or any ORM really), how would you set the back pointer from SkillGroup to TrainingProgramme? I’m assuming the ORM wouldn’t know how to do this for you, so you would have to intercede at some point.