ser que eu esteja desenvolvendo um sistema de envio de emails.A dica e: escreva uma camada de isolamento -- um [Adapter](https://en.wikipedia.org/wiki/Adapter_pattern) -- para os componentes que nao fazem parte do seu sistema. Um beneficio adicional e que voce pode usar um duble para rodar os testes, sem precisar da integracao real (o Twitter ou o email, no exemplo acima).2) Desenvolva coisas simples.Um dos principios constantes no [Zen do Python](http://www.thezenofpython.com) e:> Simples e melhor do que complexo.Nao ha quem nao concorde com isso. A questao e que desenvolvemos software para resolver problemas complexos. Seria possivel desenvolver coisas simples para resolver problemas complexos? Em software, a resposta e SIM.Um sistema grande nao precisa ser uma coisa so. Dai a origem da palavra "sistema". De acordo com a [Wikipedia](https://pt.wikipedia.org/wiki/Sistema):> Um sistema (do grego systema, atraves do latim systema), e um conjunto de elementos interdependentes de modo a formar um todo organizado.Se o que voce desenvolveu nao e formado por "elementos interdependentes" ou nao forma "um todo organizado", voce nao fez um sistema. Voce fez uma confusao.Em geral, coisas simples sao pequenas. Um exemplo que gosto muito vem dos automoveis. Podemos ter carros originais de fabrica ou "tunados". Algumas partes podem ser trocadas por outras que atendem a uma "determinada especificacao" (interface) e a coisa funciona. As vezes detalhes impedem de usar alguns componentes. Por exemplo, rodas com 5 parafusos, por mais modernas que sejam, nao encaixam em carros que esperam rodas com 4 parafusos.Alguns componentes sao mais faceis de trocar. Outros, precisam de mais capacidade tecnica. Ainda assim, varias pecas internas podem ser trocadas, desde que atendam a especificacao do fabricante. No caso do seu sistema, o fabricante e voce.Essas pecas (componentes) pequenas dos automoveis foram projetadas e desenvolvidas para funcionarem dentro de determinado contexto. Software tambem deveria ser desenvolvido assim.Um dos conceitos que reforcam esse pensamento na arquitetura de software e o [Single Responsibility Principle](https://en.wikipedia.org/wiki/Single_responsibility_principle). Infelizmente ferramentas que fazem sucesso entre nos, programadores, nao seguem esse principio que ajuda a simplificar os sistemas. Um exemplo e a forma como o ORM do Django incentiva a implementacao dos Models e Managers, levando a sindrome que chamo de Fat Model Classes e que muitas pessoas chamam de _"Fat Models"_. Mas "Fat Models" deveria significar _"camada (e nao classe) Model com regras de negocio e metodos relacionados ao negocio, divididos em varios componentes coesos"_; o que nos remete a definicao de "sistema" que lemos no inicio dessa secao.Pelo contrario, vemos em sistemas implementados usando Django as classes Model com muitos metodos e regras de negocio, auxiliadas por uma camada de servico para acesso a dados, os Managers. Essa forma de organizacao -- que viola o Single Responsibility Principle -- pode virar um problema serio de integracao quando dois programadores precisam mexer em diferentes partes da mesma classe. Afinal ela fica extensa.Nao e facil decompor um sistema em partes simples. Exige disciplina e estudo constante, mas e mais simples entender pedacos pequenos. E mais simples certificar que coisas pequenas funcionam. E mais simples garantir que um componente pequeno se encaixe em outro, tambem pequeno. Eu ouvi a palavra