title: Should the rule "one transaction per aggregate" be taken into consideration when modeling the domain?
body: <p>Taking into consideration the domain events pattern and this <a href="http://lostechies.com/jimmybogard/2010/04/08/strengthening-your-domain-domain-events/" rel="nofollow">post</a> , why do people recomend keeping one aggregate per transaction model ? There are good cases when one aggregate could change the state of another one . Even by removing an aggregate (or altering it's identity) will lead to altering the state of other aggregates that reference it. Some people say that keeping one transaction per aggregates help scalability (keeping one aggregate per server) . But doesn't this type of thinking break the fundamental characteristic about DDD : technology agnostic ?  </p>
  
  <p>So based on the statements above and on your experience, is it bad to design aggregates, domain events, that lead to changes in other aggregates and this will lead to having 2 or more aggregates per transaction (ex. : when a new order is placed with 100 items change the customer's state from normal to V.I.P.  )?</p>