Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>After completing my first project structured using the DDD principles :D, I found that it is useful to have both domain services and repositories that are available for the application layer to consume.</p> <p><strong>KEY POINT:</strong> The application layer may be your WCF services or the code in your web services if you're using that architecture. It all depends on your implementation. If it suits your implementation, your application layer may be the same as your presentation layer, thus having the application layer code in your contollers or web forms code behind.</p> <p>Repositories function like in-memory collections. To the application layer, the code should look like you're just using any old collection.</p> <p>Domain Services function more like processors or accessors to information that will never be updated, maybe processed, but not updated directly. To the application layer, the code should look like you're just using any old web service.</p> <p>That being said, I will explain more with some examples:</p> <p><strong>Repositories</strong></p> <p>My repositories actually inherit from a generic collection typed with an implementation object I created that encapsulates the database key and the business model together. Using this approach, I can define an indexer in my interface such as</p> <pre><code>BusinessObject this[int index]; </code></pre> <p>and I can have a getter that will return the business object based on the index of the underlying collection and a setter that will lookup the data key from the underlying collection and save the object to the database. This makes the application code extremely simple, for example</p> <pre><code>IBusinessObjectRepository repository = new SqlBusinessObjectRepository(sqlString); BusinessObject obj = repository[0]; //Get first object in the list. //Make some changes to the business object by setting properties or calling methods to process business logic. repository[0] = obj; //Save the object back to the database. </code></pre> <p><strong>Services</strong></p> <p>I use services to retrieve lists of entities and value objects that I am not going to edit individually and, in my case, are only used as available selections or values when calling methods on the aggregate root. Generally, I cache this information on the web server. This is not the only use for a domain service, just my example. The application layer code still remains relatively simple.</p> <pre><code>IBusinessService service = new ImplBusinessService(implementationArgs); List&lt;BusinessObject&gt; objsToCache = service.GetBusinessObjects(); //cache the objects on the web server. </code></pre> <p>In conclusion and from my understanding of DDD principles, the application layer should be able to access business objects from either services or repositories. The choice between them comes down to what fits best within the domain model. </p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload