Comments on: Life inside an Aggregate Root, part 2 http://richarddingwall.name/2009/10/14/life-inside-an-aggregate-root-part-2/ The adventures of a young kiwi software developer in London Thu, 10 May 2012 16:20:46 +0000 hourly 1 http://wordpress.org/?v=3.3.2 By: Richard http://richarddingwall.name/2009/10/14/life-inside-an-aggregate-root-part-2/comment-page-1/#comment-31986 Richard Wed, 08 Jun 2011 08:54:32 +0000 http://richarddingwall.name/?p=2244#comment-31986 @ Chris: you could pass in a <a href="http://www.refactoring.com/catalog/introduceParameterObject.html" rel="nofollow">Parameter Object</a>. However it happens, the point was that the aggregate root is responsible for creating child objects (they don't just appear out of thin air and get passed to it). @ Chris: you could pass in a Parameter Object. However it happens, the point was that the aggregate root is responsible for creating child objects (they don’t just appear out of thin air and get passed to it).

]]> By: Chris http://richarddingwall.name/2009/10/14/life-inside-an-aggregate-root-part-2/comment-page-1/#comment-31945 Chris Tue, 07 Jun 2011 15:19:34 +0000 http://richarddingwall.name/?p=2244#comment-31945 Hi, thanks for the efforts for writing these articles! They help alot. Anways, I ve got some comments (even though this post is kinda old): SkillGroup subGroup = new SkillGroup("First Aid", programmeA); programmeA.Add(subGroup); programmeB.Add(subGroup); // what happens now? I case of "what happens now?"... Inside the programme.Add-Method, couldn"t there just be the appropriate business logic? Like: public void Add(SkillGroup group) { if(group.TrainingProgramme != null) throw new DomainExpception(...); } From my point of view, one good aspect of OOD is to pass objects around. This allows, in case of refactoring, to reduce the number of contracts to be changed. In your example, if SkillGroup would have more than one property, like 10 or 20, all these need to be passed via the Add-Method, right? So if SkillGroup gets a new property later on, I must change the SkillGroup constructor, probably a factory, and the Add-method to support the new property. Do you have any experience regarding refactoring in this case? Thanks in advance Chris Hi, thanks for the efforts for writing these articles! They help alot.

Anways, I ve got some comments (even though this post is kinda old):

SkillGroup subGroup = new SkillGroup(“First Aid”, programmeA);
programmeA.Add(subGroup);
programmeB.Add(subGroup); // what happens now?

I case of “what happens now?”… Inside the programme.Add-Method, couldn”t there just be the appropriate business logic? Like:
public void Add(SkillGroup group)
{
if(group.TrainingProgramme != null)
throw new DomainExpception(…);
}

From my point of view, one good aspect of OOD is to pass objects around. This allows, in case of refactoring, to reduce the number of contracts to be changed.

In your example, if SkillGroup would have more than one property, like 10 or 20, all these need to be passed via the Add-Method, right? So if SkillGroup gets a new property later on, I must change the SkillGroup constructor, probably a factory, and the Add-method to support the new property. Do you have any experience regarding refactoring in this case?

Thanks in advance

Chris

]]> By: Richard Dingwall » Life inside an Aggregate Root, part 1 http://richarddingwall.name/2009/10/14/life-inside-an-aggregate-root-part-2/comment-page-1/#comment-10953 Richard Dingwall » Life inside an Aggregate Root, part 1 Tue, 13 Oct 2009 20:15:26 +0000 http://richarddingwall.name/?p=2244#comment-10953 [...] This is the first half of a two-part article. Read the second half here: Life inside an Aggregate Root, part 2. [...] [...] This is the first half of a two-part article. Read the second half here: Life inside an Aggregate Root, part 2. [...]

]]>