Timeline for Application architecture using CQS and DDD Aggregates
Current License: CC BY-SA 4.0
4 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 17, 2020 at 16:25 | comment | added | user3347715 | @Mike What does CQRS stand for again? I wouldn't consider a system to be employing CQRS if the write side has any knowledge of the read side. This means that any given call stack can only contain objects that are part of it's "side". This is in contrast to what VoiceOfUnreason is commenting above, but we have to understand that the entire purpose of CQRS is in recognition of the fact that the write and read sides of an application can evolve independently. Creating coupling between them can introduce regression should either change. Is this really Responsibility Segregation? | |
| Aug 20, 2019 at 17:16 | comment | added | VoiceOfUnreason | What I have found: if a use case doesn't require changing an entity in your database, then that use case should not depend on the "write repository" for that entity. It makes it a lot easier to track which code can change which parts of the model. | |
| Aug 20, 2019 at 6:07 | comment | added | Mike |
I think my question refers more to what should the OrderApplicationService (Order handler) use to retrieve the Customer object from the database. If it should use the ReadRepository (which returns the CustomerDTO), it will just call the order::calculateDiscount(isStudent), after extracting the Boolean from the DTO. However, the order handler could be injected with the CustomerWriteRepository, whose interface lives with the domain models and implementation lives at the infrastructure layer.The call could then be order::calculateDiscount(ICustomerWriteRepository) and all logic encapsulated
|
|
| Aug 20, 2019 at 1:48 | history | answered | VoiceOfUnreason | CC BY-SA 4.0 |