Acho que pra começar a falar alguma coisa sobre arquitetura e design é preciso ter uma boa noção sobre orientação a objetos e, infelizmente, não achei um lugar pra começar com facilidade. Pra corrigir esse problema eu pretendo muito em breve comprar o Object-Oriented Software Construction pra tentar extrair dele partes que tornem mais simples explicar e enteder OOP.
Com uma noção maior de OOP é hora de entender quais práticas são comuns dentro do paradigma. Recomendo fortemente o livro do Kent Beck Test Driven Development: By Example e o livro do Fowler o Refactoring: Improving the Design of Existing Code, pois as práticas se complementam e ambas influenciam diretamente na qualidade não só do seu código como também do design. Ainda nessa onda de Refactoring e Kent Beck eu recomendo a leitura do Implementation Patterns, que vai ajudar a entender melhor o conceito de estado e de quebra é uma verdadeira aula de como escrever código legível e inteligível.
A partir desse ponto deverão existir muitas e muitas referências sobre o Design Patterns: Elements of Reusable Object-Oriented Software que é um livro obrigatório para melhorar qualidade de refactorings e, principalmente, para manter um vocabulário comum de soluções para problemas já visitados, ou seja, não tentar inventar a roda e dar um nome diferente pra ela.
O Clean Code: A Handbook of Agile Software Craftsmanship com certeza deveria ser o próximo livro a ser lido porque ele vai falar das dúvidas que com certeza aparecerão com relação a exceções e seu tratamento, a organização de classes e a importância de princípios básicos, mas, que geralmente são negligenciados como The Law of Demeter. Além disso ele vai complementar a leitura do Implementation Patterns.
Aproveitando o gancho do Uncle Bob eu estou lendo o Agile Principles, Patterns, and Practices in C# pra ter maior noção de UML e poder discutir a aplicação de S.O.L.I.D numa aplicação real, ele é realmente fantástico!
Outro livro que acredito ser obrigatório para entender melhor testes (principalmente o que testar e o que não testar) e mocks (principalmente) é o GOOS. Inclusive a palestra que apresentamos recentemente no PHPSC e no Intercon é baseado neste livro.
A partir daqui acho que vou ficar devendo livros que eu realmente consegui terminar... Tenho idéia sobre o que falam e li parte considerável deles, mas, não os terminei completamente. Acho importante dar, nem que seja só uma olhada, neles:
Não sou um cara muito ligado em arquitetura e mesmo tendo lido mais livros sobre o assunto como o Enterprise Integration Patterns eu percebi que acabo deixando eles meio pra lá... Isso é, talvez, um problema da minha pessoa, mas, agora minha preocupação é escrever código que seja inteligível para outro desenvolvedor e que exprima as regras de negócio de maneira clara (usando alguma coisa de DDD nessa empreitada). Para se aprofundar em testes é bom começar pelo xUnit Test Patterns: Refactoring Test Code e depois ir procurando mais fontes ou perguntar pra outras pessoas sobre quais materiais elas tem como referência (eu ainda tenho outros livros, mas, agora a preguiça bate com força na minha pessoa pra colocá-los aqui).