title: Domain Driven Design - how the layers should be organized?
body: <p>I'm very much new to software development. I think layered architecture is a great way to reduce the complexities that arise in the process of object oriented software development and, not to mention, to keep your code organized. </p>
  
  <p>I'm interested to learn about Domain Driven Design approach and I've run into some problems to get myself introduced to it (of course, beginner level ones).<br>
  Here it is -  </p>
  
  <p>I want to build an application to save person related data in database and display person details in a WPF <code>DataGrid</code> (I know, DDD is definitely not for the apps of such scale, but just to keep things simple for an amateur like me). So, I created a domain class "Person", something like –  </p>
  
  <pre class="lang-cs prettyprint-override"><code>    public class Person
      {
          public Person(dataType paramA)
          {
              this.PropertyA = paramA;
          }
  
          private dataType _fieldA;
          public dataType PropertyA
          {
              //encapsulates _fieldA    
          }
  
          public dataType PropertyX
          {        
              //some code that manipulates private field    
          }
  
          private dataType MethodPQR(dataType param)
          {        
              //some code    
          }
      }
  </code></pre>
  
  <p>Now, my understanding of DDD says the architecture (the simplest version of it) should be as follows (please, correct me if I'm wrong) -<br>
  <img src="https://i.stack.imgur.com/jYvXp.png" alt="enter image description here">  </p>
  
  <p>Note:</p>
  
  <ol>
  <li><p>I want the <code>DataGrid</code> to be bound to some <code>ObservableCollection</code>, to reflect any kind of changes instantly.  </p></li>
  <li><p>It's a WPF application but not necessarily be in MVVM pattern and I deliberately want to use the code behind.</p></li>
  </ol>
  
  <p>My questions are -</p>
  
  <ol>
  <li><p>What kind of codes belong to the <code>Application Layer</code>?  </p></li>
  <li><p>My guess is, I should definitely not bind an <code>ObservableColletion</code> of my domain object (i.e. <code>Person</code>) as the <code>ItmsSource</code> of the <code>DataGrid</code>. What type of object then I should extract from the domain object, and how?  </p></li>
  <li><p>To keep a decoupling between <code>Presentation Layer</code> and <code>Domain Layer</code> probably there's a convention like <code>never instantiate domain objects directly in the presentation layer</code>. What are the <code>non-direct</code> approaches then?  </p></li>
  <li><p>If the code-behind talks to the <code>Application Layer</code> then should the <code>Application Layer</code> talk to the <code>Data Repository</code>? But what if some kind of domain access is needed which is <em>not</em> data access related (may be not in this app, but it may occur, right?) In that scenario, who's that <code>X</code> guy (sub-layer/module) in <code>Domain Layer</code> that the <code>Application Layer</code> should talk to?</p></li>
  </ol>
  
  <p>I know my questions are of very much amateur level, but they are questions indeed, raised from problems I'm facing to get a clear picture. So, if anybody has time, any response will be appreciated.</p>
  
  <p><strong>EDIT :</strong> I'm not sure if <code>Data Repository</code> should have a reference of <code>Domain Model</code>.</p>