Timeline for Domain-Driven Design: Cross-Domain Search
Current License: CC BY-SA 4.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 21, 2019 at 13:19 | vote | accept | JohnsonCore | ||
| Aug 21, 2019 at 3:41 | history | edited | Subhash | CC BY-SA 4.0 | added 9 characters in body |
| Aug 20, 2019 at 22:24 | history | edited | Subhash | CC BY-SA 4.0 | added 40 characters in body |
| Aug 20, 2019 at 20:41 | comment | added | Subhash | I would say it's a data-warehousing/reporting functionality. A domain would contain concepts, behaviour and invariants, and that is not the case here. | |
| Aug 20, 2019 at 20:40 | comment | added | Subhash | @DocBrown Righto, yep 👍 | |
| Aug 20, 2019 at 20:32 | comment | added | JohnsonCore | In this case, would it be off-base to describe this approach as essentially building a third domain (likely a very small one) that is essentially just forming projections from the order and account entities, or would it be more accurate to view it as a data-warehousing kind of responsibility? | |
| Aug 20, 2019 at 20:08 | comment | added | Doc Brown | I am not sure if I write an answer of my own, or if your answer already covers what I have in mind. IMHO the described use case requires to build that different data store mentioned in your answer with proper indexes optimized for the expected queries. Is it that what you describe? | |
| Aug 20, 2019 at 19:13 | history | answered | Subhash | CC BY-SA 4.0 |