title: DDD Architecture - Where To Put Common Methods/Helpers
body: <p>According to <a href="https://stackoverflow.com/questions/7436366/in-ddd-architecture-where-do-i-keep-helper-classes">this question</a> on Stack Overflow, in DDD architecture "helper" classes can be in different layers depending on their purpose. For example a helper that formats something in a user friendly way would go in the UI. A database helper would go in infrastructure. </p>
  
  <p>But what about helpers that can be used by more than one layer? For example age calculation. Age might be required in the model layer for business logic. It is used by more than one entity, so it should not be in a specific entity. Also there are places where age is required merely for display purposes in the UI. Similarly, I have string functions that can be used by more than one layer. For example my custom Right and Left methods could be used for formatting in the UI, but they might also be used in the model, for example conditional logic based on a prefix.</p>
  
  <p>So where should these common methods go? My setup is like this:</p>
  
  <ul>
  <li>UI</li>
  <li>Application</li>
  <li>Model</li>
  <li>Infrastructure</li>
  </ul>
  
  <p>Model is core and has no dependencies on infrastructure, so the common helpers cannot go in infrastructure. I am considering two options:</p>
  
  <p>1) Have another layer called Common or similar that can be used by any layer. This would create a dependency between Model and Common.</p>
  
  <p>2) Duplicate the helper logic in whatever layer is needed. Eg Have an Age helper in UI AND have an Age helper in the Model. This would violate DRY, but would not require the domain to have a dependency on a "Common" layer.</p>
  
  <p>Which option is better? Is it OK for the Model layer to have a dependency on a "common" layer?</p>
  
  <p><strong>UPDATE:</strong></p>
  
  <p>In the 2.5 years since this question was asked I have concluded:</p>
  
  <ol>
  <li>Things like Right, Left, etc that compensate for limitations in the framework, belong in a "Common" utilities / helper component that even the Model/Domain layer has a dependency on.</li>
  <li>The "Common" utilities / helper component should not be very big. With more experience I found that many things I thought of as helpers actually belong in the domain model.</li>
  <li>Age belongs in its own class in the domain layer. Much like things like address, phone number and money I consider these things as value objects. Understanding value objects really was key to my understanding of creating reusable domain classes that can be incorportated into other classes.</li>
  </ol>