Autores: James O. Coplien e Gertrud Bjørnvig. Gertrud tem mais de 20 anos de experiência em desenvolvimento de sistemas e é especialista em requisitos Ágeis. James é pioneiro em projetos OO, padrões de arquitetura e desenvolvimento Ágil de software. É autor, dentre outros títulos, de “Organizational Patterns of Agile Software Development” (Prentice-Hall, 2004).

Editora: Wiley (2010).

Site: LeanSoftwareArchitecture.com

Do que se trata: Arquitetura de Software, pensada e construída segundo princípios Lean e Agile.

Indicado para: Arquitetos, Desenvolvedores e afins. Sim, eu entrei de gaiato no navio (porque há tempos não arquiteto nem programo). Mas gostei do que vi, como testemunho abaixo.

Contra-indicações: Quem não conhecer o mínimo de OO, arquitetura de software e que tais sentirá uma certa dificuldade. Quem acha que arquitetura é burocracia, BDUF ou conversa pra boi dormir terá dois tipos de reação: espanto (positivo) ou um notável desconforto. Indiferente, acho que ninguém fica.

Breve resenha: Eu não pego um livro (técnico) que não fale sobre o que precisa ser feito e/ou gerenciamento desde os idos de 2005 e 2006, quando cismei de estudar e falar sobre SOA, Reuso e afins. Acontece que o choque do livro anterior, “Management 3.0“, foi forte demais. Vai demorar para outro livro sobre o tema me abalar tanto. Resolvi mudar de assunto. E decidi que era hora de ver o que o “outro lado” anda fazendo. Não pesquisei muito até decidir pelo livro do Coplien e da Gertrud. Mesmo sabendo que encontraria linhas de código (em Java, C++, Ruby e outras) e conceitos que talvez fossem grandes demais para minha cabecinha.

O que me chamou a atenção foi exatamente a presença da Gertrud como co-autora, dada sua especialização em requisitos. Desconfiei que não seria um livro tradicional sobre arquitetura de software. E estava certo. Vou arriscar um resumo em um parágrafo:

Se você é verdadeiramente Ágil, a arquitetura projetada por ti deve saber acomodar mudanças. Não só em tempo de projeto, mas durante todo o ciclo de vida de um sistema. Para tal, desde o início você deve saber distinguir coisas que mudam com menos frequência daquelas que mudam ‘quase todo dia’. Os autores sugerem uma divisão bem simples: O-que-o-Sistema-É é uma parte mais estável, é a forma – o pensamento do usuário; O-que-o-Sistema-Faz é a porção mais dinâmica, mais suscetível a mudanças, é o comportamento – a ação do usuário. O respeito pelo ‘modelo mental do usuário’ e a preocupação em fazer com que todos os elementos da arquitetura sejam representações fiéis deste modelo guiam todo o livro. Os letrados a antenados já devem ter desconfiado que esse papo todo desemboca no uso dos padrões MVC-U (Model-View-Controller-User. Não se incomode, é o mesmo velho MVC demonstrando simpatia pela parte mais importante do problema) e seu novo complemento chamado DCI (Data, Context and Interaction), duas crias de Trygve Reenskaug.

Resumo dado, tempo para outras considerações. Sim, esse papo de “representação fiel do modelo mental do usuário” rola, sem muito sucesso, desde a segunda metade da década de 1960 (quando surgiu OO). E sim, letrados e antenados não devem ver muito valor no livro. Como eles não são tantos assim, como atestam as aplicações que vemos por aí, o livro deve atrair um bom público. O público nerd, tratado exatamente desta maneira no texto, deve se satisfazer com as dezenas de páginas (de um total de 357) com puro código. Além de três capítulos nomeados “Coding it Up …”, o livro dispõe de seis apêndices tratando um mesmo exemplo em Scala, Python, C#, Ruby, Qi4j (segundo os autores, a melhor forma de implementar DCI em Java) e Squeak. E, como já coloquei, C++ e Java não são ignoradas. Se eu curti esse tanto de código? Olha, deu pra lembrar porque não programo mais. Mas, o código é bonito, elegante.

Aliás, a proposta como um todo é bonita (e ver Beleza em coisas assim é atestado inconteste de que um pouco de sangue nerd ainda corre nestas veias). Sempre avalio uma sugestão de arquitetura através da tríade vitruviana: firmitas (robustez), venustas (beleza) e utilitas (utilidade / funcionalidade). Os autores, pelo menos na teoria, passam no teste do Vitruvius. E insistem em nos lembrar, pelo menos uma dúzia de vezes, a Lei de Conway.

Para a turma d’o que precisa ser feito: Além do primeiro capítulo, uma Introdução, outros quatro ‘falam’ com a turma do negócio, analistas, donos de produtos e afins. São eles: “3 – Stakeholder Engagement“, “4 – Problem Definition“, “5 – What the System Is, Part I: Lean Architecture” e “7 – What the System Does: System Functionality“. Vou destacar os pontos que mais me chamaram a atenção.

Gostei muito da separação incondicional de o-que-o-sistema-É de o-que-o-sistema-FAZ. Quando estudamos um negócio, também devemos ter esse tipo de preocupação. Separamos a Visão da Estrutura da Visão dos Processos, cientes da maior complexidade e volatilidade da segunda. Costumo dizer em meus treinamentos que a Visão dos Processos ocupará, no mínimo, 70% do tempo de um analista de negócios. Acontece que a aplicação tradicional ou indisciplinada de conceitos OO, em determinado momento, mistura tudo. Através do padrão DCI essa separação é sempre respeitada. Entre a estrutura (Data, o D de DCI) e o-que-o-sistema-FAZ (Interaction), sempre há um Contexto. E um Contexto é uma representação fiel de… um Caso de Uso!

Qual não foi minha surpresa quando vi os autores ‘ressuscitando’ as Especificações de Casos de Uso. Segundo eles, de forma bem direta, o mundo Ágil reinventou a roda com as Histórias de Usuários e todos os seus ‘complementos’ (Mapas de Histórias, Dependências, Restrições, Test Cases etc). Casos de Uso oferecem, segundo os autores, consolidação de todas as informações necessárias para a construção d’o-que-o-sistema-FAZ. Há muito em comum entre a sugestão do livro e o modelo de casos de uso que aplico. Por exemplo: “O Fluxo Principal não deve ter mais que 7 passos!”; “Questões sobre interface do usuário e projeto do sistema são melhor representadas em outras ferramentas, não em casos de uso“. E por aí vai. E vai tão longe que merecerá um artigo específico.

Por ora, fica minha curiosidade em saber como os desenvolvedores tupiniquins estão vendo a proposta. Fiz uma breve pesquisa no Google e em alguns grupos de discussão e não vi uma única menção ao termo DCI. Como a comunidade Ruby só faz crescer por aqui, pensei que acharia algo. Mas talvez eu não tenha procurado direito. Lá fora as reações são variadas e algumas bem iradas, como mostra esta thread. Aliás, estou para ver o dia em que novas ideias de nossa área não virarão um Fla X Flu.

Enfim, duas coisinhas que me incomodaram: i) Não há um único diagrama UML no livro. Mesmo que os autores defendam fervorosamente a ‘modelagem com código’, deveriam entender que um ou outro diagraminha poderia facilitar a compreensão de alguns conceitos; ii) SOA morreu? Sinceramente, não esperava ler um livro sobre arquitetura de software escrito em 2010 que praticamente passa em branco pelo assunto. Os autores até justificaram no início do livro a ausência, mas não foram muito convincentes. Ou, de fato, SOA morreu?