Abordagens da Decomposição de Software

Dando continuidade ao artigo de introdução a decomposição de software, estas não são as únicas maneiras de fazer isso, no entanto são as que utilizei ou utilizo no meu dia-a-dia.

É importante lembrar que cada plataforma também influenciará no processo de decomposição devido a seu estilo de construção e conceito de usabilidade. Eu falo isso porque é importante respeitar a tecnologia e não tentar impor o seu jeito de fazer as coisas, caso elas não elas estejam do jeito que se está acostumado.

Um erro muito comum é começarmos a modificar/estender algo sem entender corretamente o seu funcionamento.

Evolução das Abordagens de Modelagem de Software

Abaixo apresento alguns marcos que considero importantes na evolução da engenharia de software. É importante salientar que não estou considerando do ponto de vista dos paradigmas de modelagem, como: orientação a objetos, funcional, procedural, lógica, etc.

A ideia é iniciar dos primeiros métodos de organização em forma de módulos de software, sejam eles classes, funções, componentes, bibliotecas até formas modernas baseadas em sistemas de padrões, usando SOLID, DDD, etc.

O meu estudo de arquitetura de software coincidiu com essa ordem, mas ela não é obrigatória. Outro dia assisti a uma palestra no youtube sobre OCAP - Object Capability Systems e o desenvolvedor nem "conhecia" DDD, ele fez uma piada a respeito.

Fiz essa referência porque você pode optar por seguir uma linha mais linear e explorar todas as possibilidades dela sem prejuízo na carreira. O que não pode é misturar as coisas sob pena de tornar a manutenção mais complexa.

Abaixo segue a forma como progredi nos estudos de arquitetura, primeiramente aprendi a organizar por módulos, até mesmo por que ANSI C foi minha primeira linguagem de programação. Depois aprendi orientado a pessoas, aprendi a trabalhar a relação requisitos versus implementação e por último capacidades na are da orientação a dados.

Estudar formas diferentes de fazer alguma coisa é uma excelente forma de reciclar conhecimento e principalmente de não repetir erros passados. Pessoalmente eu também uso para identificar tendências.

Modelagem orientada a Módulos

Essa é a forma mais simples que conheço de organização e talvez seja a primeira feita com intuito de agilizar o desenvolvimento de software, pois modularizando era possível paralelizar o desenvolvimento.

Para definir essa metodologia vou usar o artigo Critérios a serem usados na decomposição de sistemas em módulos do David L. Parnas de 1972. Sim ele é antigo mas vale a leitura. Os critérios avaliados por ele focavam em 3 problemas que enfrentamos até hoje:

• Gerencial: Possibilita que vários grupos possam trabalhar em módulos diferentes de maneira independente.

• Flexibilidade: Possibilita a realização de mudanças drásticas num módulo sem impactar os demais.

• Compreensibilidade: Possibilita o estudo e entendimento dos módulos individualmente.

Ao meu ver dois pontos importantes podem ser observados aqui, quando ele fala de mudanças:

1. Fazer mudanças drásticas não significa mudar a interface do módulo mas apenas a estrutura interna.
2. O modelo de interação entre os módulos foi definido em um momento anterior dando liberdade para o desenvolvimento de cada módulo em si.

É importante considerarmos que apesar dos métodos ágeis aparentemente "eliminarem" etapas do desenvolvimento, quando ele simplifica o fluxo de execução na verdade ele a distribui em ciclos menores.

Esses ciclo menores poderiam ser considerados fatias verticais em um processo sequencial, pessoalmente gosto de imaginar a execução de um método ágil conforme a figura abaixo.

Em todos os meus projetos, procuro fazer reuniões onde as soluções são discutidas de maneira a gerar os direcionamentos do desenvolvimento.

Agilidade é habilidade de conseguir equilibrar pessoas, processos e tecnologia, conforme falei na primeira série de artigos do portal.

Quando eu estava iniciando no desenvolvimento de software esse tipo de abordagem facilitou bastante meu aprendizado, pois as outras formas são muito mais complexas e exigem uma abstração muito maior.

Em javascript eu ainda acho muito interessante usar esse tipo de abordagem, mesmo após a liberação da versão doECMA Script 6 com a exposição da possibilidade de usar "classe". Em javascript essa abordagem é chamada de AMD - Asynchronous Module Definition, ela foi muito utilizada em frameworks, como: backbonejs, PureMVC e agora vejo similaridades no Vue.js.

Modelagem orientada a Pessoas SOLID

Essa abordagem foi chamada assim, por que conforme as palavras do próprio Uncle Bob no Livro Clean Architecture, abaixo segue uma tradução do que ele escreveu.

"Um módulo deve ser responsável apenas por um ator. ", do livro Clean Architecture

Classifiquei o SRP - Single Responsibility Principle ou Princípio da Responsabilidade Único como foco em pessoas, por que ele tenta dar um direcionamento mais especializado que a abordagem modular.

Além dele considero também fazem parte desse sistema de padrões o OCP - Open-Closed Principle e Liskov Substituion Principle, que organizam o desenvolvimento das funcionalidades e os dois últimos Interface Segregation e Dependency Inversion Principle eu os considero como complementares e utilitários. Eles dão suporte a implementação dos 3 primeiros.

Nessa abordagem achei uma contribuição bem interessante, a aplicação indireta de conceito apresentado na série de livros Pattern-Oriented Software Architecture que é Sistema ou Linguagem de Padrões que diz:

Uma rede de padrões que se constroem uns aos outros, como uma árvore ou grafo direto, dessa maneira um padrão pode opcionalmente ou obrigatoriamente influenciar em outro, elaborando o projeto de um jeito especial e se adaptando conforme a necessidade.

No caso o SOLID, pode ser implementado com Factories, Stragety, Decorator se apoiando no Dependency Inversion por exemplo segue um exemplo do desenho de uma funcionalidade que aplica os princípios propostos pelo SOLID com o objetivo de suportar duas versões dela.

Modelagem orientada a Negócio DDD

Chamo de abordagem focada no negócio, por que você se apoia no comportamento do domínio do negócio.

A partir das iterações você identifica as barreiras de consistência mais adequadas para o fluxo que se está projetando, o Vaugh Vernon uma série de artigos sobre modelagem de agregações que são excelentes, pessoalmente recomendo o livro Implementando DDD.

Achei a modelagem de agregação a contribuição mais interessante do DDD, pois com a definição de agregações você identifica os objetos do negócio requeridos para dado contexto, isso é o que chamo de consistência.

Dessa maneira é possível brincar com o seu modelo de objetos e otimizar para escrita, consulta e até mesmo avaliar o grau de complexidade do domínio.

Uma excelente contribuição do DDD é nos ensinar a dar nomes, tudo conforme o vocabulário do domínio ao se projetar com foco no comportamento. Como exemplo considere o seguinte cenário:

1. Produtos em um mercado qualquer podem estar nas gôndolas, podem ter promoções e estar numa prateleira.
2. Um produto pode ser colocado numa prateleira
3. Um produto pode ser posto em promoção

À esquerda temos uma única agregação como ponto de acesso e devido a isso, temos um grupo de entidade muito grande, um seja uma transação envolvendo muitos objetos para fazer qualquer modificação num produto.

À direita temos outro problema, pois teremos produtos que não estarão em promoções e nem em prateleira alguma. Este é um exercício interessante a ser feito, essa série vale a leitura.

A busca pelas agregações raiz que são os responsáveis por controlar o acesso as demais entidades de um grupos de objetos, vai definir a forma como você organiza as relações entre os objetos, bem como número de grupos e tamanho desses grupos.

Se do ponto de vista conceitual, o ferramental disponibilizado pelo DDD te ajuda a entender o domínio através do comportamento, por outro lado a arquitetura não é trivial. Seu sistema de padrões é muito mais complexo, envolendo um conjunto de conceitos, abstrações e padrões necessários muito maior, como: Repository, Service, Value Object, Entity e outros.

É um dos modelos arquiteturais mais avançados que existem é resiliente, parece pensado para refatoração sob a ótica do negócio, todas as regras de negócio ficam enclausuradas não apenas em uma camada, mas num grupo de objetos que delimita o acesso as entidades daquele cenário específico.

Essas características te permitem fazer mudanças pontuais nas agregações desde que não modifiquem a sua identidade.

A arquitetura DDD ao mesmo tempo expõe a sua aplicação para testes, eu aprendi a projetar e organizar testes unitários e a aplicar TDD durante os estudos desse modelo arquitetural.

Eu classifiquei DDD como orientada ao negócio, por que realmente ela pode ser a arquitetura da sua camada operacional da empresa. As agregações vão organizar seus domínios e poderão evoluir com eles.

O uso de eventos irão gerar um histórico do legado e os repositórios de dados podem ser implementados de forma estratégica para expor seus dados de diferentes formas.

Através do padrão de projeto Repository conforme descrito no capítulo 13 do livro de referência Patterns of Enterprise Application Architecture, que diz:

Ele pode ser muito útil em sistemas, bancos de dados com múltiplos esquemas ou objetos de domínio.

Ou seja, esse padrão é estratégico, apesar dele não ter recebido a devida atenção do livro, no entanto é um padrão extremamente poderoso, principalmente em empresas que desejam se tornar orientada a dados.

Se você precisa integrar as sua aplicações conforme visões, ex: Operacional, Gestão e Estratégica, esse padrão é perfeito para isso.

A flexibilidade do DDD facilita a adoção da melhor tecnologia para armazenar seus eventos ganhando consistência, bem como, utilizar projeções de dados para otimizar a leitura, dessa maneira você não precisará que o seu time de análise de dados fique copiando e reprocessando dados numa etapa de limpeza, o que não considero ser uma atividade que eles não deveriam fazer.

Abaixo segue o desenho da arquitetura de referência de uma aplicação DDD já considerando um modelo estratégico alimentando bases para visão estratégica e de gestão com um modelo dimencional atráves do modelo OLAP e um orientado a coluna no caso com o HBase.

Modelagem orientada a Capacidades ECS

Para a última categoria desse artigo eu gostaria de apresentar um modelo arquitetural que vem do mundo dos jogos. Esse modelo pode agregar muito valor ao mundo das arquiteturas orientadas a eventos e que suportam concorrência nativamente, no caso é a ECS - Entity Component System.

Ela também pertence a linha evolucionária da arquitetura baseada em componentes e ligada ao movimento DOD - Data Oriented Design, esse tipo de arquitetura é altamente performático e apresenta um modelo de objetos baseado em composição e não mais em herança. Abaixo seguem alguns exemplos de propriedades que são bem interessantes para o momento atual:

• Paralelismo nativo
• É Event Sourced por padrão
• Estruturas de dados que trocam herança por Composição
• Separação completa entre dados e lógica estruturalmente
• Altamente flexível

Abaixo segue um exemplo de diagrama mostrando os três principais componentes da arquitetura. As entidades apenas como um mero objeto identificador para agregá-las.

Os componentes sendo as características apresentados como as propriedades, os sistemas sendo os responsáveis pelo processamento das mudanças nas características das entidades e o gestor como um orquestrador de tudo.

Apesar de praticamente todos os frameworks que utilizam essa abordagem serem para o desenvolvimento de jogos, o rumo atual dos modelos de desenvolvimento é na das EDA - Event Driven Architectures e as soluções são escritas como sistemas CEP - Complex Event Processing.

A primeira postagem que encontrei a respeito desse tipo de abordagem de ECS foi no site T-Machine de 2007, porém o artigo Evolua sua hierarquia é um clássico escrito pelo Mick West. Existem outras abordagens dessa arquitetura, porém unificam sistemas e componentes, o que não é interessante.

Essa arquitetura é daquelas que a simplicidade dificulta o entendimento. É necessário um pequeno exercício de abstração para visualizarmos o uso dessa arquitetura fora do mundo do jogos digitais. Mas, vale a pena experimentar.

Considerações Finais

Finalizo aqui mais uma série, desta vez sobre decomposição, minha ideia foi mostrar que existem diversas formas de olhar para um problema e desenha uma solução, cada uma com suas características e desafios.

Vou tratar de todas essas arquiteturas em mais detalhes no futuro, talvez em um treinamento que possibilite abordar devidamente o assunto.

Espero que essa série sirva para abrir a mente em tempos de transformação digital, apresentei uma amostra das possibilidades, que são muitas, e vale a penas o estudo de cada uma, pois irá lhe ajudar a organizar melhor suas ideias de maneira a avaliar o custo da sua solução a longo prazo e seu impacto no sistema.

Dúvidas, sugestões? Basta perguntar, a pior pergunta é a que não foi feita.

Tags: arquitetura | dataorientdesign | ddd | dod | domain-driven | dominio | ecs | entitysystem | eventdriven | modelagem | ocap | sistemadeentidades | software | solid