Hi Yegor, when I read "architecture" in the title and saw your cover image of a house in the form of a sitting cat I wondered when IT architecture will be as mature as building's architecture, so that we can design software applications with an architecture resembling a cat... not because it makes sense, but just because we can (without breaking the application). 😃
But let's get to your article. You're using the terms "layer" and "tier", so it's important that we have a common definition of these terms. On Wikipedia it says that "tier" is used for physical separation, while "layer" simply means a logical separation. You also use the term "architectural level", which I would use synonymously with "layer". I'm not so sure if you do the same, because you claim that MS Office and GIMP just has one "architectural level". I'm pretty sure that's not true (when "level" means "layer"). It might run on a single machine, yes, so it's just a 1-tier application (as long as you don't connect MS Access to a remote database, which is absolutely possible).
One of your claims is that a single tier application has the disadvantage that it's harder (you even say impossible) to patch after delivery to the production with the example of games in the '90s. I would argue that the ability to patch something has nothing to do with the number of machines the application is running on. What you probably mean is the deployment model: do parts (tiers) of the application run centralised at the developer company or do all parts run on-prem at the customer's site? In the 90's we couldn't ask that question, because the Internet wasn't as wide-spread as today and it was very slow. Applications simply couldn't run with separate tiers over the Internet. But still we had patches for games. At the end of the 90's they were already distributed over the Internet, but at the beginning of the 90's we bought journals that included CD-ROMs containing patches for games. It wasn't the only way of patch distribution, there were also BBS'es and the FidoNet.
However, I really can't stress enough how important clear definitions (and deliberate usage) of terms are when looking at your description of "Event Bus":
This template mainly interacts with events and has 4 main components: event source, event listener, channel and event bus. Sources place messages for specific channels on the event bus. Listeners subscribe to specific channels. Listeners are notified of the appearance of messages posted on channels from their subscription
See? You introduce a new term at the end which is not part of your description of an event bus. So are there 5 components in an event bus? No. The term "subscription" belongs to the publish-subscriber pattern, not to an event bus.
I don't want to disappoint you with my feedback - I actually love to see articles about software architecture here on dev.to and would like to see more of them. Maybe just focus on a smaller topic next time and be more concise with your terms, I really think this is important.
so that we can design software applications with an architecture resembling a cat... not because it makes sense, but just because we can (without breaking the application). 😃
Hah, I also liked it. Some coding methods are not so easy to use, and implementation of some features, that users can ask from developers of certain software solutions - can be pretty difficult. But that's only in those cases, when software development company does not have developers, who can handle those issues. I know some great dev companies, and one of those you can find here on site , it's called Miquido. Those guys are true dev professionals, and they know for sure how to implement almost everything you would like.
Hi Yegor, when I read "architecture" in the title and saw your cover image of a house in the form of a sitting cat I wondered when IT architecture will be as mature as building's architecture, so that we can design software applications with an architecture resembling a cat... not because it makes sense, but just because we can (without breaking the application). 😃
But let's get to your article. You're using the terms "layer" and "tier", so it's important that we have a common definition of these terms. On Wikipedia it says that "tier" is used for physical separation, while "layer" simply means a logical separation. You also use the term "architectural level", which I would use synonymously with "layer". I'm not so sure if you do the same, because you claim that MS Office and GIMP just has one "architectural level". I'm pretty sure that's not true (when "level" means "layer"). It might run on a single machine, yes, so it's just a 1-tier application (as long as you don't connect MS Access to a remote database, which is absolutely possible).
One of your claims is that a single tier application has the disadvantage that it's harder (you even say impossible) to patch after delivery to the production with the example of games in the '90s. I would argue that the ability to patch something has nothing to do with the number of machines the application is running on. What you probably mean is the deployment model: do parts (tiers) of the application run centralised at the developer company or do all parts run on-prem at the customer's site? In the 90's we couldn't ask that question, because the Internet wasn't as wide-spread as today and it was very slow. Applications simply couldn't run with separate tiers over the Internet. But still we had patches for games. At the end of the 90's they were already distributed over the Internet, but at the beginning of the 90's we bought journals that included CD-ROMs containing patches for games. It wasn't the only way of patch distribution, there were also BBS'es and the FidoNet.
However, I really can't stress enough how important clear definitions (and deliberate usage) of terms are when looking at your description of "Event Bus":
See? You introduce a new term at the end which is not part of your description of an event bus. So are there 5 components in an event bus? No. The term "subscription" belongs to the publish-subscriber pattern, not to an event bus.
I don't want to disappoint you with my feedback - I actually love to see articles about software architecture here on dev.to and would like to see more of them. Maybe just focus on a smaller topic next time and be more concise with your terms, I really think this is important.
Challenge accepted! 😂
Hah, I also liked it. Some coding methods are not so easy to use, and implementation of some features, that users can ask from developers of certain software solutions - can be pretty difficult. But that's only in those cases, when software development company does not have developers, who can handle those issues. I know some great dev companies, and one of those you can find here on site , it's called Miquido. Those guys are true dev professionals, and they know for sure how to implement almost everything you would like.
Like this? 😄
Thanks for you feedback! I really appreciate this and I will try to concentrate on something specific