A developer with M.Sc. in Computer Science. Working professionally since 2010. In my free time I make music and cook.
Also I don't and after the recent events will not have Twitter.
Location
Budapest
Education
Eötvös Loránd University (ELTE - Budapest Hungary) Computer Science M. Sc.
So what is the best approach for small/medium companies in terms of development and having a stable test environment?
Going with a monolith (if you don't have a ton of users/functionality you are going to be fine with it) and maybe with a couple of Lambdas?
I started programming in 1995 with Microsoft BASIC on MS-DOS from a book I found in my father's library, and I slowly (having no real mentors) learned other programming languages by myself.
Seems to me like every systems development veteran out there recommends the loosely coupled monolith approach for 90% of use cases (the other 10% is for cases where you know from the start that your system will serve possibly hundreds of thousands of users concurrently, or more).
There's nothing wrong with monoliths if they are done right (DDD, SOLID, CQRS (which has nothing to do with event-based architectures), Patterns, etc.).
If the monolith is loosely coupled (CQRS, Mediator pattern, Interfaces) and generally well tested, then when it's REALLY NEEDED, for scaling and cost reduction reasons, refactoring to another architecture SHOULD BE EASY and should be possible to do in gradual steps (one endpoint/resource/feature at a time), thanks to the loose coupling (outside-in dependency injection, and other great patterns).
Software, if it continues to enjoy constant use, should evolve, and refactoring is how that happens. So it's not a bad thing if you gradually start to evolve your software application to another architecture style, if that is made possible by having designed the system with this thought in mind from the start.
So it really seems to me like knowing good software design patterns, especially those pertaining to loose coupling and CQRS, is more important than what software architecture style you're going to start with.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
So what is the best approach for small/medium companies in terms of development and having a stable test environment?
Going with a monolith (if you don't have a ton of users/functionality you are going to be fine with it) and maybe with a couple of Lambdas?
Seems to me like every systems development veteran out there recommends the loosely coupled monolith approach for 90% of use cases (the other 10% is for cases where you know from the start that your system will serve possibly hundreds of thousands of users concurrently, or more).
There's nothing wrong with monoliths if they are done right (DDD, SOLID, CQRS (which has nothing to do with event-based architectures), Patterns, etc.).
If the monolith is loosely coupled (CQRS, Mediator pattern, Interfaces) and generally well tested, then when it's REALLY NEEDED, for scaling and cost reduction reasons, refactoring to another architecture SHOULD BE EASY and should be possible to do in gradual steps (one endpoint/resource/feature at a time), thanks to the loose coupling (outside-in dependency injection, and other great patterns).
Software, if it continues to enjoy constant use, should evolve, and refactoring is how that happens. So it's not a bad thing if you gradually start to evolve your software application to another architecture style, if that is made possible by having designed the system with this thought in mind from the start.
So it really seems to me like knowing good software design patterns, especially those pertaining to loose coupling and CQRS, is more important than what software architecture style you're going to start with.