https://aosabook.org/en/

These are available to read completely free online, but I do plan to purchase the physical books some day.

[edit] I realize that I should probably give more context to my answer. The books on the site are basically interviews with the authors of the software and they discuss what choices they made as well as the advantages/tradeoffs of this approach. In other words, the direct answer to your question is to learn by reading what other people have written about their own successes and glean from that.

[edit 2] Your favorite LLM could also provide a list of books that are similar in spirit, but there's just something about the series that I linked to that I like.

Building something real from scratch, like a small SaaS or side project, can help you learn a lot.

Using AI is not a bad thing in itself, but you should treat it as an assistant rather than a crutch. When AI gives you an answer, ask yourself "why this approach?" and evaluate the response critically from multiple angles. When you build with that mindset, you naturally develop good architecture instincts, both by understanding the AI's reasoning and by pushing back on it.

Personally I would recommend starting with a Discord bot. I started learning programming by building a discord bot with dashboard before ChatGPT existed, and looking back it was a surprisingly good way to develop architecture sense. The scope is flexible, even if it is built just for yourself, it can grow as complex as you want. You can keep adding features over time, and every new feature forces you to think about how it fits into what already exists. And that friction is where the learning actually happens.

> I realize I don’t have much knowledge about the best way to architect applications

There is no “best way”, it always depends on what you are building.

The main advice I would give is to always remember that there’s trade-off’s in every architectural choice…

I guess some general tenants might be… “great architectural solutions…”

- Allow new features to be added, without much complexity

- Have reliable and clear abstraction layers

- Allow tests and typing to validate it’s correctness

- Manage clearly understood limitations, rather than implicit surprise limitations

The only thing I can think of is to ask the AI "why this instead of that?"

Every architectural decision is a tradeoff between something and another. Every technology choice is also a tradeoff. If you understand the reasons for the choices you'll start understanding architecture.

Sometimes it starts with requirements (ie: what you're trying to do), or what your deployment environment looks like, your hosting provider, or even what technology static you'd rather use.

For example, I'd never use Java for a project ever again; it's unclear what it really brings to the table, and it's more difficult to deploy on AWS. And if I was going to use Java I wouldn't pick Spring or any other dependency injection framework because they inevitably lead to impossible-to-debug performance issues. I wouldn't use an ORM for the same reason. No Ruby as well, due to issues with migrations and active record. No postgres unless there was a specific feature of it that works better than other, due to RDBMS management overhead and inconsistencies.

Of course, now that I write this my next project is going to be some random Java/Spring/pgsql thing with a Ruby engine attached (aargh).

What helps actually is reading the "why you should use this tool" parts of each tool. You can start building a mental model/checklist of the good/bad things of each one and why would you use one instead of the other. There's almost always more than one tool available, and the way you deploy/scale/manage/backup each one will tell you a lot about when you would (or wouldn't) use it.

In general don't worry about scale until you're at the point you can test for scalability. I mean, some architectures are better than others, but all of them will be performant at 10 users. Even flat files, a bash web server, and bash-based CGIs can handle 10 users.

Good software architecture - that allows to avoid mistakes that costs you a lot at the end. So you need to see many systems with that mistakes and see what did the become at the end, than you will be able to spot bad decisions at the very beginning. So path of tries and mistakes and gaining experience. Without experience even if you read or learn some good practice - without deep deep understanding why it is good - you can badly apply it

I have been programming long before LLMs, and it was painfully slow, but the lessons stayed with me for a long time, and after some time I was able to spot architectural problems before they became problems, because I suffered many times before.

When I'm building with AI now, it's much faster, yeah, but it's extremely difficult to learn these patterns, so I feel like slowing down the pace when working with LLMs (although very difficult), and researching things properly will allow you to develop these muscles, and bring benefits in the long run.

I enjoyed a lot reading the book and also learned a few things there: The Pragmatic Programmer, 20th Anniversary Edition. The main guiding principle: Good design is easier to change than bad design

i'd say by practice is the fastest one, just making something - then looking at some part and searching how to improve it or how to make it more efficient, then you find the architecture designs someone is using and start testing it on your own code. This way you can fully understand and explain the impact of applying it.

Continuously and deeply reading and understanding high-quality open-source code repositories - these resources are easy to find, but they require patience. With the help of LLMs, this process will be much easier than before.