Software architecture refers to the fundamental structures of a software system and the discipline of creating such structures and systems. Each structure comprises software elements, relations among them, and properties of both elements and relations.
In other words, architecture is more about how information is processed and stored in the system, not how parts of system are packaged. On high level architectural diagrams packaging often even not mentioned as part of the architecture.
Of course, packaging has influence on the architecture, for example, cross-service transactions are big no-no for the microservices. Those limitations and specifics should be taken into account during design. But in general microservices usually is a traditional service-oriented architecture with added headache and limitations.
Just one example from real life: about 6 months ago I worked on the application which consisted of 2 microservices. After some small refactoring it was possible to package application as either monolith or as 2 independent microservices. The architecture of the whole system remained unchanged and internal differences between packaging localized in 2 (two) classes.
Ahh I think I understand you a bit more.
I also think there are different aspects and levels of an architecture.
A whole software has an architecture.
A single service has an architecture.
Packaging is part of an architecture but not the whole architecture itself.
When speaking of a monolith I think the whole software (not a single service) is meant. How the packaging is handled is somehow unrelated to this meaning (but is still part of the architecture). This is my opinion and I don't think that there is one right answer for this.
I still disagree. Packaging relationship to architecture is similar to relationship of technology stack - language/framework/platform/DB/cloud/etc. It has influence on architecture (for example, it might be necessary to add Circuit Breakers at some points), but architecture in general remains unchanged.
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.
Software Architecture
In other words, architecture is more about how information is processed and stored in the system, not how parts of system are packaged. On high level architectural diagrams packaging often even not mentioned as part of the architecture.
Of course, packaging has influence on the architecture, for example, cross-service transactions are big no-no for the microservices. Those limitations and specifics should be taken into account during design. But in general microservices usually is a traditional service-oriented architecture with added headache and limitations.
Just one example from real life: about 6 months ago I worked on the application which consisted of 2 microservices. After some small refactoring it was possible to package application as either monolith or as 2 independent microservices. The architecture of the whole system remained unchanged and internal differences between packaging localized in 2 (two) classes.
Ahh I think I understand you a bit more.
I also think there are different aspects and levels of an architecture.
A whole software has an architecture.
A single service has an architecture.
Packaging is part of an architecture but not the whole architecture itself.
When speaking of a monolith I think the whole software (not a single service) is meant. How the packaging is handled is somehow unrelated to this meaning (but is still part of the architecture). This is my opinion and I don't think that there is one right answer for this.
I still disagree. Packaging relationship to architecture is similar to relationship of technology stack - language/framework/platform/DB/cloud/etc. It has influence on architecture (for example, it might be necessary to add Circuit Breakers at some points), but architecture in general remains unchanged.