You don't start by choosing an architecture. You start by understanding the problem and the pieces in the solution space. You then figure out how those pieces can work together to solve the problem. After that you can see the system as nested subsystems and interactions, which you can draw as diagrams and call it an architecture.
So I see "architecture" more as a teaching and communication technique, applied after the fact. Altho since we're always moving between the details and the big picture, having organized abstractions (ie an architecture) in mind will help keep the design clean.
The architecture evolves and sharpens as a system comes together. And this evolving architecture provides the team with a common terminology and overall direction.
But you rarely start by choosing a specific architecture. Unless you already know a lot about your solution.
It really depends. Some patterns might be specific to problem domains, but a layered architecture applies pretty much across all types of software projects.
Between defaulting to a layered architecture and just mindlessly piling up ad hoc decisions without any coherent criteria, a layered architecture always wins.
Honestly - a layered approach ends up paying dividends even if used solely for code organization. Options like microservices and event frameworks work quite well when using layered approaches internally.
Basically, I've seen SQL in controllers and I don't ever want that again.
depends, some systems are such that all they are doing is pumping SQL results into JSON, in that case, I don't want to see some general purpose programming language in the controller. Which is kind of the idea behind https://postgrest.org/ ( written in haskell if anyones interested )
If all you're doing is pumping SQL into json, you should either be generating code, or if you don't care about performance using a dynamic language with meta-programming techniques such that you write almost 0 code to achieve your results.
> But you rarely start by choosing a specific architecture. Unless you already know a lot about your solution.
That's how it probably should be, but in my experience it rarely is.
Generally, businesses decide that they need to re-/implement x, then the enterprise architect shows up and decides on the pattern and then the developers are required to somehow make it work, even if it objectively doesn't.
These patterns are so vague and high-level that you could just throw a dart in one of them and it'd work OK for whatever some company is doing. Almost no one is solving issues that can only be described in one pattern.
If anything people are too caught up in the idea that there decisions are make or break for a business.
I guess theoretically if the enterprise architect knew about the project and its requirements, the pattern should probably have matched the intended outcome...
Don't pick the right tool for the job, pick the right framework which secures you extra work for being a tool. - @iamdevloper ... via https://github.com/globalcitizen/taoup
So I see "architecture" more as a teaching and communication technique, applied after the fact. Altho since we're always moving between the details and the big picture, having organized abstractions (ie an architecture) in mind will help keep the design clean.
The architecture evolves and sharpens as a system comes together. And this evolving architecture provides the team with a common terminology and overall direction.
But you rarely start by choosing a specific architecture. Unless you already know a lot about your solution.