Some people just "get" software architecture and some don't.
Part of it is indeed experience, but another part of it is just being able to visualize the entire application (domain experience helps with this) and see it as a series of interconnected modules. Think of the parts individually and what downsides they have and than as a whole.
An example of this is if you have a module that does something very GPU heavy or very bandwidth heavy. On an architecture layer you want want to give it it's own server outside of the main server (in the case of a web app).
In terms of code you need to think about how some modules will need to be updated in the future (want to support multiple payment methods) - and also to think what modules need to be secure or performant. If two modules will always exist together they might be something you can couple if it saves you a large amount of developer time. But if they might be re-used in the future they need their own API's and no close coupling.
Part of it is indeed experience, but another part of it is just being able to visualize the entire application (domain experience helps with this) and see it as a series of interconnected modules. Think of the parts individually and what downsides they have and than as a whole.
An example of this is if you have a module that does something very GPU heavy or very bandwidth heavy. On an architecture layer you want want to give it it's own server outside of the main server (in the case of a web app).
In terms of code you need to think about how some modules will need to be updated in the future (want to support multiple payment methods) - and also to think what modules need to be secure or performant. If two modules will always exist together they might be something you can couple if it saves you a large amount of developer time. But if they might be re-used in the future they need their own API's and no close coupling.