title: DDD - how to rehydrate
body: <blockquote>
    <p><strong>Question</strong>: what is the best, efficient and future proof way to
    rehydrate an aggregate from a repository? What are the pro's and con's of the provided ways and are my perceptions correct?</p>
  </blockquote>
  
  <p>Let's say we have an Aggregate Root with private setters but public getters for accessing <em>state</em> </p>
  
  <p>Behaviour is done through methods on the aggregate root.</p>
  
  <p>A repository is instructed to <strong>load</strong> an aggregate. </p>
  
  <p>At the moment I see a couple of possible ways to achieve this:</p>
  
  <ol>
  <li>set the state through <strong>reflection</strong> (manual or automatic eg.
  Automapper) </li>
  <li>make <strong>constructors</strong> that accept properties so state is set</li>
  <li>load the aggregate with a <strong><a href="https://lostechies.com/gabrielschenker/2015/05/25/ddd-the-aggregate/" rel="noreferrer">state object</a></strong></li>
  </ol>
  
  <p>1) <a href="https://lostechies.com/jimmybogard/2009/09/18/the-case-for-two-way-mapping-in-automapper/" rel="noreferrer">Jimmy Bogard</a> alludes that his tool <strong>Automapper</strong> isn't meant for two-way mapping. But some people argue that we have to be pragmatic, use tools in a way it helps you.</p>
  
  <p>For me, I don't like a <em>full</em> rehydration through reflection. Maybe Automapper ceise to exist or aggregate roots are bent in such a way the mapping can be done (see some comments of <a href="https://vaughnvernon.co/?p=879" rel="noreferrer">Vaughn</a> on his article).</p>
  
  <p>2) creating <strong>constructors</strong> for rehydration, with a couple of parameters so the state of the aggregate is rehydrated in a correct way.</p>
  
  <p>These couple of parameters can expand (= new constructors) or the definition can change. I like this approach, except the part of having a bunch of parameters.</p>
  
  <p>3) the <strong>state</strong> is a property of the aggregate root. The state is encapsulated in a new object and this object is build by the repository and is then given to the aggregate root for proper init. </p>
  
  <p>Some people argue that building this state object is <em>more</em> work (new class, exposure of state properties on entity and aggregate root to enforce business rules), but it provides a clean way to initiliaze the state.</p>
  
  <p>Say that we need event sourcing, does the loading of a state resemble in loading events? And does the state object provide a way of handling events? Is it more future proof?</p>