title: DDD and Persistence. Again
body: <p>I am struggling with persistence in Domain Driven Design. As far as I understand, domain model should never be persistent-aware. Let's say I am building a simple todo-list application. I have a task with following interface:</p>
  
  <pre><code>interface ITask
  {
     bool IsCompleted {get;}
     string Description {get;}
  
     void Complete();
     void ChangeDescription(string description);
  }
  </code></pre>
  
  <p>And the generic implementation should look like this:</p>
  
  <pre><code>class SimpleTask : ITask
  {
      public SimpleTask(string description)
      {
         ChangeDescription(description);
      }
  
      public bool IsCompleted { get; private set; }
      public string Description { get; private set; }
  
      public void Complete()
      {
         IsCompleted = true;
      }
  
      public void ChangeDescription(string description)
      {
         // some validation here
         // ...
         Description = description;
      }
  }
  </code></pre>
  
  <p>I want to have a description be necessary - because it's a business rule. So from this moment if I want to save this object via serializers I will fail because no parameterless constructor provided. And I shouldn't provide it because of no persistance-aware rule. If I model my task in a form of DTO\POCO I will end up with another problem - so called anemic model. Moreover, I don't want to provide setters to some properties.</p>
  
  <p>So where is the solution to all of this? I can create a tightly-coupled saver that will know how to save and restore task state. But I can access only public properties and methods, what if internal logic of task will be complex and impossible to save\restore? Should I mark all fields in task internal and have a possibility to save inner state of object? Isn't it kinda code smell and violation of no persistence-aware rule?</p>
  
  <p>How do you solve this?</p>