Implement application work flow

[misha130]

This tasks refers to how in this project data should be queried from. This flow should be universal and used for all the queries.

It can be:

• CQRS with Mediatr. Basically separating all the requests to commands and queries and creating handles, behaviors with mediatr to handle these. Some examples https://lostechies.com/jimmybogard/2015/05/05/cqrs-with-mediatr-and-automapper/
• EventSourcing - Having one source for events - https://github.com/oskardudycz/EventSourcing.NetCore
• UseCases - http://www.plainionist.net/Implementing-Clean-Architecture-UseCases/ Which raphaelschmitz did in his https://bitbucket.org/raphaelschmitz/answers/src/master/
• Repository/Service simple structure. CLASSIC DDD

Feel free to add. (I realize there is no forum thread about this but I feel its too technical to post on the forum)

[ranolfi]

The architecture I had in mind, discussed with some of our core developers (mainly by voice call), and am currently implementing in my ranolfi/skeleton branch is the last one from your list: classic DDD with repository/service.

[raphaelschmitz00]

I don't know if this is decided yet, but wanted to chime in about CQRS/UseCases: They are basically the same.

The term "UseCases" in that form comes from Clean Architecture, where it makes sense in context of the rest of the architecture. But in essence, CQRS's "commands" and "queries" are just both called "use cases".

However, I would advice against Mediatr (and automapper, actually). We use that combination at work and are now trying to get rid of them again. Which is work, but it's the work that we should just have done in the first place.

The problem is, like they say in Python, "explicit is better than implicit". Concerning Mediatr, using the generic IRequestHandler everywhere makes it way harder to see what is actually being used; you lose the overview. Concerning AutoMapper, if you use it like intended, refactoring a property name breaks it, without the compiler telling you anything about it. You CAN do everything explicitly, too, but even its creator Jimmy Bogard says to better use C# itself without AutoMapper in that case.

[misha130]

I don't know if this is decided yet, but wanted to chime in about CQRS/UseCases

It was decided to do repositories/services back in nov/dec. I checked with Marc. I even made two branches one CQRS and one with repositories to fortify the decision and repositories was chosen again.

Also I agree 100% on the Automapper. And regarding mediatr people really accept this as a fact that in any event driven system its harder to understand where its going. Its a downside (I see the same thing on frontend for example)

[ranolfi]

@raphaelschmitz00 and I actually had a call (via Discord) where we discussed a little bit about these different design approaches :) @DoctaJonez provided some good perspectives too, and there were more discussions in some of our channels, prob. #backend or #tech-lead-comms.

For reference to anyone who lands here in the future - as I suggested in our last conversation over Discord (@misha130), the concern regarding the CQRS approach when applied to the rest of the architecture is somewhat of an excessive or "unwarranted" abstraction. I mean, by introducing additional indirection to data access logic, it deviates further from the KISS principle for little benefit in this particular scenario, so we go with the "simpler"¹ approach.

I agree with what has been said about AutoMapper, generally.

⁽¹⁾: so to speak.

[GRMule]

Browsing issues here, getting my environment set up, I can't advocate enough for the classic architecture. It's the easiest to walk in to; the new school and specialized stuff is a barrier to contribution.