title: DDD / Aggregates in .NET
body: <p>I've been reading Evans' book on DDD and am thinking about how one should implement aggregates in .NET. Currently, I can only come up with one way; isolating the aggregates in separate class libraries. This, however, seems like a bit of overkill (I'd prefer to keep all domain objects in one library) and I wonder if there is a different way?</p>
  
  <p>The reasoning for the 1 lib/aggregate is as follows: The aggregate root needs to be aware of all access to 'sub-objects' it is responsible for, also the aggregate root can return sub-objects as results of its members. Therefore, members (needed by the aggregate root) of these sub-objects can't be made public. So your only option is making them internal (since they still need to be called by the aggregate root). By putting all aggregates in one project, however, it is still possible to access these members from other domain objects that have obtained the sub-object. This is undesirable because it allows one to bypass the aggregate root. By separating all aggregates in different libraries this problem is solved.</p>
  
  <p>Some additional info:</p>
  
  <p>I've checked out the <a href="http://dddsample.sourceforge.net/" rel="nofollow">DDD java sample code</a> and they pack every aggregate (including all sub-objects' classes) in a different package. Members that can only be called from the aggregate root have no access modifier (for example: <code>Delivery.updateOnRouting</code>). In java, members without access modifier are <a href="http://download.oracle.com/javase/tutorial/java/javaOO/accesscontrol.html" rel="nofollow">package-private</a> (available only from the same package). So this would be correct behavior.</p>
  
  <p>The <a href="http://dddsamplenet.codeplex.com/" rel="nofollow">.NET sample code</a>, however, puts all domain objects in one class library, and then makes the corresponding members public. To me, this seems incorrect.</p>