Timeline for Can the Application Service layer create an instance of a non aggregate root?
Current License: CC BY-SA 3.0
16 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 8, 2017 at 8:32 | vote | accept | w0051977 | ||
| Nov 7, 2017 at 17:33 | comment | added | w0051977 | I guess you are saying that if you delete a customer in memory, then you still want to retain all of their invoices in memory. However, if you delete a customer from the database, then you delete all of their invoices from the database (hence your: ON DELETE CASCADE comment above). | |
| Nov 7, 2017 at 17:31 | comment | added | Doc Brown | @w0051977: yes, I think those standard UML terms are what I have in mind. | |
| Nov 7, 2017 at 17:21 | comment | added | w0051977 | Last question (which I think will clarify it for me). What is the difference between a "reference" (you use this term in a comment above) and a component? Are you referring to association and composition respectively as described here: stackoverflow.com/questions/885937/…). | |
| Nov 7, 2017 at 17:18 | comment | added | Doc Brown | @w0051977: quite the opposite, if an Invoice would be a component of a Customer, it would be loaded immediately, not lazily. | |
| Nov 7, 2017 at 17:16 | comment | added | w0051977 | In that case; I don't understand what you mean by: "Just because there is 1:n association between customers and invoices does not make invoices automatically components of a customer. ". If there is a lazy loaded Invoice reference collection then surely it is a component of the Customer class. | |
| Nov 7, 2017 at 17:12 | comment | added | Doc Brown | @w0051977: well, this depends on the details of the implementation, the implementation language and the ORM (if there is one). The references could be lazy loaded by the ORM, or by the Customer objects itself (which should get an InvoiceRepository passed for this purpose). Or the application context does this and wires them together. | |
| Nov 7, 2017 at 17:10 | comment | added | w0051977 | Thanks. Could you confirm what you mean by a collection of references? Do you mean a collection of GUIDs (assuming the Primary Key field of Invoice is a GUID) or a collection of Invoices that are lazy loaded from the database? | |
| Nov 7, 2017 at 16:52 | comment | added | Doc Brown | @w0051977: I did not say a Customer cannot have a collection of Invoices (actually, it could have a collection of references to the related invoices, if you mean that). But that does not mean the lifetime of the Invoice objects are coupled to the related Customer. If you have requirements for dealing with Customers without invoices, and vice versa, model them both as invidual Domain objects with an association between them, not one as a component of the other. | |
| Nov 7, 2017 at 16:38 | comment | added | w0051977 | Thanks. However, I don't understand why it is suboptimal. There is a relationship between Customer and Invoice in the database so a Customer should have a collection of Invoices as a property. Could you explain why this is not right? + 1 for the first line of the answer. | |
| Nov 7, 2017 at 16:29 | comment | added | Doc Brown | @w0051977: standard Normalisation rules can be applied as well to DDD classes, but for this case, it makes no difference: lets assume for a moment you model an Invoice as an aggregate of a Customer and ignore the fact this is suboptimal. That would give you the same tables on the database. However, you would deal with those tables differently in your application when loading records into domain objects, and you might add an "ON DELETE CASCADE" constraint to the CustomerID foreign key column in the Invoice table | |
| Nov 7, 2017 at 16:21 | history | edited | Doc Brown | CC BY-SA 3.0 |
added 95 characters in body
|
| Nov 7, 2017 at 16:15 | comment | added | w0051977 | Thanks. Is there a set of guidelines that can be used to design DDD classes? When designing databases you have Normalisation. Is there something similar for the Domain Classes? (which would perhaps show that Invoice is not a valid property of Customer). | |
| Nov 7, 2017 at 16:13 | history | edited | Doc Brown | CC BY-SA 3.0 |
added 159 characters in body
|
| Nov 7, 2017 at 16:07 | history | edited | Doc Brown | CC BY-SA 3.0 |
added 159 characters in body
|
| Nov 7, 2017 at 16:06 | history | answered | Doc Brown | CC BY-SA 3.0 |