This roadmap needs more stuff

[assetkad]

In most cases, there will be microservices at work that will use DDD or EDA and something from clean architecture and these things are very important in this roadmap i didn't see it

[paillave]

In most cases, there will be microservices at work that will use DDD or EDA and something from clean architecture and these things are very important in this roadmap i didn't see it

DDD or the art of writting too much code for nearly no advantage. It was a fantastic architecture pattern when it was reelased in 2003: at the time when it was defined by its author, frameworks almost didn't exist, tooling was quiet poor, and C++ was still THE language to go.

Nowaday, some overengineering freaks are trying to find a way to push for this overwritting code pattern just to show off with the excuse of "yeah, you know... microservices... it's something that must be strong, fast, and scalable... so we must use a many pattern as possible. DDD is the best man! And I order you not to wonder why, since it was created 20 years ago, nearly nobody in real world actually uses it". From my experience, every team I know who tried it wasn't conviced of its advantages, and at the end of the day, it created more problems than the solutions it is supposed to solve. So every body came back to the good old regular injectable service pattern.

Even microsoft doesn't really recommend it in their documentation for microsoervices. Actually in microsoft technologies, the way to go for microservices is Orleans. It solves nearly all problems we can deal with when developing scalable architecture with microservices, but doesn't need these quintilions of files and lines of dramaticaly non straight forward code.

I know my speech can sound very rude for DDD fanatics, but seriously, for teams who consider DDD... just be veeeeeeeeeeeeeery careful because this arcthitectural pattern comes with very very very big cost.

[assetkad]

I gotchu. But in defense of DDD, it's good for business and for developers because there will be a connection between them. So in your opinion most on Higload projects which pattern is used? DDD? Orleans?

[rexebin]

I would say use whatever make sense to the business, but explore the options. Evolve if needs to be. Anything leads to functional and maintainable solutions are good.

[paillave]

I gotchu. But in defense of DDD, it's good for business and for developers because there will be a connection between them. So in your opinion most on Higload projects which pattern is used? DDD? Orleans?

as a matter of a fact, trying to make business understanding some sort of structured description of what they want as an application is a chimeria. They absolutely don't care of our UML diagrams and they refuse to understand anything related to IT, even if we believe they can and should understand UML or anything that is related to analysis. Sometimes they even believe IT is just a job of translator between our natural language and programing language, or that is it as easy as repairing a car. It's a sad fact, and if business people were willing to make this effort, no doubt we would all move around with fliying car, or maybe teleportation or even time travel would be invented.

Now, since we accept this fact, we must come back to something that is reliable and maintainable. As Nb Bugs = x * LOC, it is always a good practice to reduce the amount of code. (and don't be wrong, this doesn't mean writting quick and dirty!).

[Elfocrash]

DDD is intentionally left outside of the roadmap in the same way Clean Architecture and Vertical Slices have been left outside. I will make a video on why DDD is not in here at some point.