New answers tagged

0

It seems like solution #1 is the way to go for what (I think) you want, with solution #2 being a possible performance optimization you could add later, if necessary. It sounds like you'll already have a list of the shops, so that part isn't a problem. Even if each shop's data is stored in its own text file, I don't think it will take all that long to parse ...


0

To cut a long story short, this is mostly a matter of self-imposing a design and then trying to make something fit. Something which is very much needed, but doesn't quite fit with the design we imposed on ourselves. In the end, it's a matter of finding the compromise in your design that you're comfortable with. Below, I've listed the common compromises I've ...


0

This confusion is not your fault. The literature sucks. Some state that is ok to put this query in repository others say is not good because is not an entity "Repository", in a DDD discussion, refers back to the REPOSITORY pattern described by Eric Evans in Chapter 6 of the original domain driven design book. Evans, in that chapter, explicitly ...


1

MVC and CQRS are apples and hand grenades. MVC is about routing user actions from a view and returning data. CQRS is a data access pattern to avoid side effects in queries and provide a simple scaling solution. Part of the problem is that model is probably one of the most used words in patterns and not all of them are mutually exclusive. MVC and CQRS can be ...


0

Before taking the question on. It would be worth going in to the overview of CQRS What is CQRS? As you said CQRS is about separating the write model and read model Some benefits of CQRS The reading logic of the application could have quite some complexity to show different types reports. Splitting the models out makes the write model simpler to implement ...


Top 50 recent answers are included