RES: Should I put this Invariant within a domain service or aggregate itself?
"Thiago Antunes Fernandes Oliveira [email protected] [domaindrivendesign]" <[email protected]> Mon, 18 May 2015 20:21:15 +0000
| Newsgroups | gmane.comp.programming.domain-driven-design |
|---|---|
| Message-ID | <9BC3002907ABF44EAFAFB50ADF2D2ADF39B010AA@SRV-EXCHANGE.allbras.com.br> |
HI, I’m new in DDD, but I think you could solve this problem to publishing a service in Sales aggregate and not in Deals aggregate. Deals aggregate in my opinion should be consumed by Sales Aggregate. If you are checking purcharses values, the method can’t be published from deals aggregate. If you do that a bidirectitional dependency will happen. Thinking about services orquestration, I would publish an service on the application layer of the Sales Aggregate called “AddToChart” and inside this service I would call “CheckPurchaseLimit” (The service published at Domain Layer of the Sales aggregate). This “CheckPurchaseLimit” method will find active deals for the product passed as parameter and return the validated rules to “AddToChart” method. The deals aggregate should be used just to keep the rules of product deals and never call the methods of the sales aggregate. De: [email protected] [mailto:[email protected]] Enviada em: segunda-feira, 18 de maio de 2015 15:31 Para: [email protected] Assunto: [domaindrivendesign] Should I put this Invariant within a domain service or aggregate itself? I'm working on a side project to learn and apply DDD within the "Daily Deal' domain. In my purchasing context, i have an invariant where a user can only purchase 'x' amount of deals per deal. so it seems wasteful for my deal aggregate to load all purchases from all users just to check and see how many times (if any) the user has purchased this deal. I see two ways i could go about this. 1. Put this logic within a domain service which would allow a pre-condition to already have been met when the Purchase method on the Deal aggregate is invoked. 2. My repository implementation could always populate the purchases collection of the deal for the purchasing user. hmm...not sure about this one. any guidance would be great! ________________________________ ALLBRAX | CREATIVE E-GOV SOLUTIONS Thiago Antunes Fernandes Oliveira Desenvolvedor - Tributário • +55 16 3515-5200 Ramal 5209 - Ribeirão Preto/SP • [email protected]<mailto:[email protected]> Antes de imprimir pense em sua responsabilidade e compromisso com o MEIO AMBIENTE!