Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<blockquote> <p>Should the factory be calling directly into the repository to get its data or the service library?</p> </blockquote> <p>I'd say neither, it should be passed the information it needs directly if at all possible.</p> <blockquote> <p>Where does the factory fit into the following framework: UI > App > Domain > Service > Data</p> </blockquote> <p>Not sure where this layering is coming from, layers are not fixed in DDD but I'd say you'd be best focussing on this style</p> <p>UI > App > Domain</p> <p>Within the Domain you then have multiple types of objects and I'd set rules about the relationships between them:</p> <ul> <li>Factories should be passed everything they need to do their work, I thus wouldn't have them calling out to other services or repositories in most cases.</li> <li>In most cases entities should not contact repositories, instead services (or other upper layers) should be responsible for this work. </li> <li>Entities should not call services, services sit on top of the entities/value objects/specifications and co-ordinate them as appropriate.</li> <li>Services within the domain are there to co-ordinate, they don't contain significant domain/business behavior.</li> </ul> <blockquote> <p>If the role of the factory class is for object creation then what benefits does the service layer have?</p> </blockquote> <p>Eric explains this quite well in the book so I'd refer to it, but ultimately its great if you have cross aggregate behavior or behavior that doesn't fit well into one aggregate (e.g. the account example in the book).</p>
 

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