No último post demos um overview sobre performance, e os termos e medidas citados no livro Patterns of Enterprise Application Architecture de Martin Fowler.

Neste post, iremos dar uma introdução à Patterns, falaremos também, sobre a estrutura dos padrões e as limitações dos padrões apresentados no livro.

Vamos falar sobre PATTERNS!

“Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice” [Alexander et al.]

Resumidamente, Patterns são soluções particulares, que resolvem um ou mais problemas recorrentes. Geralmente, esses problemas foram enfrentados, estudados, resolvidos, e catalogados. Existem diversos catálogos (ou livros) voltados a patterns que resolvem diferentes tipos de problemas, como por exemplo:

• Patterns of Enterprise Application Architecture -- Martin Fowler (este que estamos realizando a imersão)

• Design Patterns: Elements of Reusable Object-Oriented Software - GOF (Mais conhecido)

• Microservices patterns - Chris Richardson

• Enterprise Integration Patterns - Gregor Hohpe and Bobby Woolf

• entre outros...

Um ponto muito importante citado por Fowler no P of EAA, é que você não precisa ler tudo deste livro, ou todos os livros de patterns para considerá-lo útil. Basta, você ler o suficiente para ter uma noção de quais são os padrões, quais problemas eles resolvem e como eles os resolvem. Você apenas precisa do suficiente para saber que se encontrar um dos problemas, você irá encontrar este padrão no livro. (Por isso costumo chamar de catálogo) :hehe

Identificando o pattern a ser utilizado para resolução do seu problema, você precisará então, descobrir como adaptar o pattern à suas circuntâncias. Nunca aplique suas soluções, caso não tenha problemas. Caso contrário, você poderá gerar problemas em sua aplicação.

Dentro do livro P of EAA, cada pattern é independente, mas os patterns não são isolados. Muitas vezes um pattern leva a outro, ou ocorre apenas se outro for. Por exemplo, você só irá ver um Class Table Inheritance, se você houver um Domain Model no seu design.

Um dos maiores ganhos dos patterns, é principalmente auxiliar na comunicação. Se seus colegas de equipe possuem conhecimento, por exemplo, em o que é um Data Transfer Object. Permite que comuniquem facilmente, dizendo "Essa classe é um DTO" e todos já teriam um entendimento do escopo desta classe.

Estrutura dos patterns

Em todos os livros de pattern, geralmente os autores precisam escolher seu "pattern form". Neste tópico, iremos listar os itens do"form pattern" utilizado no livro P of EAA.

• Nome do Pattern: Este é um item muito importante quando se falamos de patterns, desta forma, é possível criar um vocabulário para facilitar a comunicação entre os "designers".
• Intenção e Esboço: A intenção geralmente resume o pattern em uma ou duas linhas. O esboço, é representado geralmente por diagramas UML. Com esses itens é possível gerar uma breve lembrança do que é esse pattern e como ele funciona para que possa recorrer rapidamente a ele.
• Problema motivador: Este pode não ser o único problema que o pattern resolve, mas é o que o autor cita o problema que mais motiva a utilização do padrão.
• Como funciona: Descreve a solução. É colocado em discução sobre as tarefas de implementação e variações encontradas.
• Quando utilizar: Descreve quando o pattern deve ser utilizado. É falado também sobre os trade-offs para escolher uma solução, comparada a outras.
• Leitura adicional: Pontua outras discussões sobre o pattern.
• Exemplos: Exemplo simples do pattern em uso. Neste livro, os exemplos estão em Java ou C#. Mas, sempre que realizarmos a análise de algum pattern, irei realizar em PHP. (everything is possible!) :)

Limitação destes padrões

The patterns here are all ones that I’ve seen in the field, but I’m not going to claim I completely understand all of their ramifications and interrelationships. This book reflects my current understanding, and that understanding has developed as I’ve been writing the book. I expect it will continue to evolve long after this book has turned into paper. One certainty of software development is that it never stands still. (Martin Fowler)

Sempre que estiver considerando o uso de um padrão, nunca se esqueça que é um ponto de partida, e não o ponto final. Este livro foi escrito focado em fornecer um inicio. Lembre-se que todo padrão é incompleto e você tema a responsabilidade e o desafio de completá-lo, encaixando ao contexto de seu sistema.

Conclusão

Realizamos a imersão na introdução do livro, entendemos sobre o que são Enterprise Applications, sobre Performance, e neste post demos uma introdução a Patterns. No próximo post, iremos falar sobre Layering, assunto do primeiro capitulo do livro. Espero que estejam curtindo e aprendendo algo com esse conhecimento adquirido e compartilhado! Muito obrigado por ler até aqui <3