Couldn't agree more, that architecture has to be evolutionary process. I liked the 2nd, updated definition, that architecture is a snapshot of shared understanding that the expert developers have of the system design. I even want to expand on it by saying, that "time" is the most important factor. Maybe at the moment your monolith application is "perfect", with team of 3 developers and 100 users using it. Once your application scales to 30 developers with 3 teams and 10000 of users, situation might be different. I don't agree with the first Ralf Johnson definition though: - It's the stuff we wished we could get right at the start of the project. It implies that we made mistakes in the beginning, but architecture is a moving target, whether it's good or bad might largely depend on if you evaluate it "yesterday", "now" or "tomorrow". A good software architect should be in constant pursuit for perfection, but always behind the target. You should be able to say, that it's GOOD for CURRENT situation, and it is nearly PERFECT for YESTERDAY`s situation. For instance, it's OK to start with monolith and see how far you can go, but you should always be aware of your constraints and try to address them before they start becoming problematic. And all these *ilities is not something that drives architecture design, but rather it's something that must be maintained all the time in order to have a working project that is able to evolve.
Nothing wrong with monolith, specificallt modular monolith which follows DDD in terms of contexts. This way we can start with single app without of the all overhead of microservices and if we scale up we can split whichever module we need into separate app and team. The hardest part is defining the contexts itself and to keep them loosly coupled.
Interesting points. Caveat: 14:32 ❝if you are Netflix or Amazon, [then microservices are] fantastic. If you are a small dev. shop […] it's almost certainly overkill.❞ 💬Not necessarily: if microservices are provided by 3rd parties, then they will be useful regardless of company size. Buying is generally more cost-effective than building it yourself.
You are my Carl Sagan in the Software space. Thanks for sharing your thoughts!
Interesting comment. But, I don’t think computer science has a great science communicator like Carl Sagan, Richard Feynman etc.
Good clear thinking David. Like it
16:53 love that quote
Couldn't agree more, that architecture has to be evolutionary process.
I liked the 2nd, updated definition, that architecture is a snapshot of shared understanding that the expert developers have of the system design.
I even want to expand on it by saying, that "time" is the most important factor. Maybe at the moment your monolith application is "perfect", with team of 3 developers and 100 users using it. Once your application scales to 30 developers with 3 teams and 10000 of users, situation might be different.
I don't agree with the first Ralf Johnson definition though: - It's the stuff we wished we could get right at the start of the project.
It implies that we made mistakes in the beginning, but architecture is a moving target, whether it's good or bad might largely depend on if you evaluate it "yesterday", "now" or "tomorrow".
A good software architect should be in constant pursuit for perfection, but always behind the target. You should be able to say, that it's GOOD for CURRENT situation, and it is nearly PERFECT for YESTERDAY`s situation. For instance, it's OK to start with monolith and see how far you can go, but you should always be aware of your constraints and try to address them before they start becoming problematic.
And all these *ilities is not something that drives architecture design, but rather it's something that must be maintained all the time in order to have a working project that is able to evolve.
Nothing wrong with monolith, specificallt modular monolith which follows DDD in terms of contexts. This way we can start with single app without of the all overhead of microservices and if we scale up we can split whichever module we need into separate app and team. The hardest part is defining the contexts itself and to keep them loosly coupled.
Who can do a code review on vscode source code to explain its plugin architecture to the people
I can do it for Eclipse's Plugin System 😉
Some real world examples on how the theory was applied would help.
lol, what do you want to call those NFR?
here, from 0:55 to 1:55, jim coplien shows how to recognise a software architect: ruclips.net/video/3txy_maxtk8/видео.html
Interesting points. Caveat: 14:32 ❝if you are Netflix or Amazon, [then microservices are] fantastic. If you are a small dev. shop […] it's almost certainly overkill.❞ 💬Not necessarily: if microservices are provided by 3rd parties, then they will be useful regardless of company size. Buying is generally more cost-effective than building it yourself.