Timeline for DDD, creating an aggreagate from outside the application service layer
Current License: CC BY-SA 3.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 21, 2013 at 5:39 | comment | added | Orposuser | About CQS, AKA CQRS, that's pretty true for most of the scenarios however you still want to return an id, if generated internally so your client can use it as identifier. Agree on the early id generation but, like with any technique, one should apply on a case by case basis | |
| Nov 20, 2013 at 7:45 | comment | added | Stefan Billiet | About early id generation: 1)No they don't. Generally, you use Guids for that and Guids are for all intents and purposes in this context unique. So in Java, you have UUID.randomUUID(). JS has github.com/broofa/node-uuid. 2)See number 1 3)See number 1. Frankly in my experience, you need early id generation, because you need ids for sending commands that touch multiple entities. Otherwise it becomes very hard to build any sort of dynamic application without a gazillion roundtrips to the server. Not to mention the fact that creating something should not return anything (according to CQS). | |
| Nov 19, 2013 at 17:58 | vote | accept | Orposuser | ||
| Nov 19, 2013 at 17:55 | comment | added | Orposuser | I agree on calling the factory from foo service that makes sense because: 1) hide the creation details from clients of the application service, 2) that will bring flexibility because clients doesn't need to know about how to create the aggregate. The id generation can be discussed in another topic but looks not desirable to me because 1)if the clients generates ids then they need to know about the internals of my domain logic and 2)also I could have some collision of ids if id generation is poorly implemented, finally 3)breaks encapsulation | |
| Nov 19, 2013 at 7:23 | comment | added | Stefan Billiet | Where? In this case, probably in your fooservice. Why? Why do you wish to put logic about instantiating an aggregate and all the possible business logic that that entails, in another place than said aggregate? Ah id generation. Especially in DDD apps (but frankly in general as well), I would strongly advise you to generate your ids clientside, because that will save you a lot of unnecessary roundtrips and will make things much easier for you. If you use Guids for ids, you will have that flexibility. | |
| Nov 18, 2013 at 23:21 | comment | added | Orposuser | Where should I call this factory?, inside the application service? I don't really understand why... Because I should return an instance of Foo that contains the id of Foo plus. | |
| Nov 18, 2013 at 8:49 | history | answered | Stefan Billiet | CC BY-SA 3.0 |