29 de julho de 2026
Arquitetura de aplicação para conexão entre clientes e prestadores de serviço utilizando Domain-Driven Design
Eduardo Ferreira Lima; Lucas José de Souza
DOI: 10.22167/2675-6528-202600760
Artigo elaborado pela ferramenta ResumeAI, solução de inteligência artificial desenvolvida pelo Instituto Pecege voltada à síntese e redação.
Resumo
A crescente necessidade de integrar serviços heterogêneos em sistemas digitais evidenciou desafios relacionados ao acoplamento excessivo, à dificuldade de evolução arquitetural e à preservação da lógica de negócio. O trabalho teve como objetivo investigar e avaliar de que maneira os princípios do Domain-Driven Design (DDD) contribuíram para a modelagem do domínio, a organização arquitetural e a integração de serviços heterogêneos em um sistema de conexão entre clientes e prestadores de serviços a domicílio. Para isso, realizou-se uma pesquisa aplicada, de abordagem qualiquantitativa e caráter exploratório, desenvolvida por meio de estudo de caso único. A metodologia envolveu levantamento de requisitos com 44 participantes, análise textual e semântica das respostas, modelagem estratégica e tática do domínio, e o desenvolvimento de um protótipo funcional em arquitetura limpa. A validação arquitetural baseou-se na complexidade ciclomática dos módulos, na cobertura de testes automatizados e no tempo médio de incorporação de integrações externas. Os resultados indicaram baixa complexidade estrutural na maior parte dos módulos, elevada capacidade de verificação do sistema e incorporação controlada de novas dependências externas, especialmente nos componentes protegidos por camadas anticorrupção. A abordagem adotada demonstrou potencial para favorecer a modularidade, a testabilidade e a evolução incremental da solução, contribuindo para reduzir o impacto das integrações externas sobre o núcleo do negócio.
Palavras-chave: Acoplamento; Camada anticorrupção; Integração de sistemas; Modularidade; Testabilidade.
1. Introdução
A integração de serviços heterogêneos em sistemas digitais representa um desafio persistente no desenvolvimento de software. A complexidade inerente a essa integração frequentemente resulta em acoplamento excessivo entre os componentes, dificultando a evolução arquitetural e a manutenção da lógica de negócio. A dependência de múltiplas integrações externas pode comprometer a estabilidade e a escalabilidade das aplicações, conforme observado por Newman (2021) e Pressman (2010).
Nesse cenário, plataformas que visam conectar usuários a prestadores de serviços a domicílio enfrentam desafios adicionais. A gestão de agendamentos, pagamentos, geolocalização e comunicação entre diferentes fornecedores cria um ambiente de alta complexidade e interdependência. Tal contexto revela uma lacuna significativa em projetos que buscam harmonizar integrações externas sem sacrificar a integridade do núcleo de negócio ou incorrer em ciclos de evolução excessivamente complexos.
Para endereçar essas problemáticas, o “Domain-Driven Design” (DDD) emergiu como uma abordagem promissora. O DDD propõe estruturar o software em torno de conceitos do domínio, utilizando objetos de valor, agregados e contextos delimitados. Essa abordagem visa reduzir ruídos semânticos e fortalecer a coerência do modelo, conforme detalhado por Evans (2004), Avram e Marinescu (2006), e Vernon (2016). A orientação para a construção de modelos mais compreensíveis e semanticamente consistentes é um de seus pilares.
A aplicação dos princípios do DDD é particularmente relevante em ambientes com múltiplas integrações. A delimitação de contextos, por exemplo, é crucial para gerenciar a complexidade e os padrões de uso estratégicos. A utilização de uma Camada Anticorrupção (ACL) permite mediar a relação com serviços externos, preservando os contratos e reduzindo a contaminação semântica do modelo de domínio, conforme discutido por Vernon (2013), Evans (2004) e Ford et al. (2017). Essa separação é fundamental para evitar que as particularidades de sistemas terceiros impactem a lógica de negócio central.
A relevância deste estudo reside na necessidade de compreender como as práticas de desenvolvimento de software podem mitigar os desafios impostos pela integração de serviços heterogêneos. A dificuldade em manter a lógica de negócio íntegra e a arquitetura evolutiva diante de constantes mudanças externas justifica a busca por abordagens que promovam maior modularidade e testabilidade. A avaliação empírica de como o DDD contribui para esses atributos é, portanto, de grande valor prático e teórico.
A pesquisa se justifica pela busca por soluções que permitam a construção de sistemas mais resilientes e adaptáveis, capazes de evoluir incrementalmente sem comprometer o núcleo do negócio. Diante desse cenário, o objetivo desta pesquisa foi investigar e avaliar de que maneira os princípios do “Domain-Driven Design” contribuíram para a modelagem do domínio, a organização arquitetural e a integração de serviços heterogêneos em um sistema de conexão entre clientes e prestadores de serviços a domicílio, o que envolveu o desenvolvimento de um protótipo de aplicação como estudo de caso. Para viabilizar essa investigação, a análise estruturou-se a partir de três indicadores complementares: a complexidade ciclomática por módulo, a cobertura de testes automatizados e o tempo médio necessário para incorporar novas integrações externas.
2. Material e Métodos
Este estudo configurou-se como uma pesquisa de natureza aplicada, com abordagem metodológica mista, combinando elementos quantitativos e qualitativos. O propósito foi investigar como os princípios do Domain-Driven Design (DDD) contribuíram para a modelagem do domínio, a organização arquitetural e a integração de serviços heterogêneos em um sistema de conexão entre clientes e prestadores de serviços a domicílio. A pesquisa foi conduzida por meio de um estudo de caso único, envolvendo a concepção e o desenvolvimento de um protótipo de aplicação. O processo de pesquisa estruturou-se em quatro etapas sequenciais: levantamento de requisitos, modelagem da arquitetura de domínio, desenvolvimento do protótipo e validação sistêmica. Essa organização permitiu investigar a modularidade, testabilidade e capacidade evolutiva da arquitetura, conforme o objetivo do estudo.
A primeira etapa consistiu no levantamento exploratório de requisitos, realizado por meio de questionários estruturados aplicados entre maio e junho de 2025. A população-alvo, composta por 44 potenciais clientes e prestadores de serviços a domicílio, incluiu participantes maiores de idade e residentes no Brasil. O instrumento foi desenhado sob os fundamentos do Domain-Driven Design (Evans, 2004; Vernon, 2016) e princípios de elicitação centrada no usuário (Patton, 2014).
Essa etapa adotou uma abordagem dual, refletindo a necessidade de Contextos Delimitados e vocabulários distintos para clientes e prestadores (Vernon, 2013). O questionário integrou métricas quantitativas e questões qualitativas para extração de terminologias e conceitos recorrentes, alinhando o vocabulário dos usuários à modelagem técnica. As perguntas basearam-se em pilares teóricos como Linguagem Ubíqua, Identificação de Eventos de Domínio e Delimitação de Contextos.
Na segunda etapa, os requisitos levantados subsidiaram a modelagem da arquitetura do sistema, orientada pelos princípios do DDD. As informações coletadas via Google Forms foram exportadas e importadas para Python. Os dados foram submetidos a processos de limpeza, deduplicação e normalização. A nomenclatura das variáveis foi padronizada por perfis (cliente e prestador), segmentando os dados em dois conjuntos distintos, fundamentada no conceito de Contextos Delimitados (Vernon, 2016).
O pré-processamento textual das respostas abertas envolveu processamento linguístico para extração e normalização de tokens, remoção de “stop-words” e lematização. A análise quantitativa dos tokens gerou visualizações de frequências de n-gramas e histogramas. A extração de termos relevantes foi realizada por meio do método TfidfVectorizer. Adotou-se abordagem adaptada de “Knowledge Crunching” (Evans, 2004), com análise temática e validação por mapeamento de histórias (Patton, 2014). Os contextos delimitados foram classificados em Domínio Central, Subdomínio de Suporte e Subdomínio Genérico (Evans, 2004; Vernon, 2016).
A terceira etapa consistiu no desenvolvimento do protótipo, implementado como um backend monolítico modular em Python 3.9, com framework web, camada de persistência e banco de dados principal, em ambiente containerizado. Para os testes, empregou-se banco de dados em memória. O desenvolvimento guiou-se pela abordagem de Test-Driven Development (TDD), na qual cada requisito foi traduzido em casos de teste antes da implementação (Pressman, 2010).
Para a integração com serviços externos heterogêneos, implementou-se o padrão de camadas anticorrupção (ACL), atuando como camada de tradução entre o modelo de domínio e as dependências externas (Vernon, 2013). A comunicação com os consumidores da API estruturou-se sob a arquitetura Representational State Transfer (REST), utilizando o formato JSON sobre o protocolo HTTP, com validação de contratos. As integrações com serviços externos foram encapsuladas por interfaces e adaptadores específicos, e a notificação operacionalizada por interfaces e adaptadores de envio.
Por fim, a validação da arquitetura concentrou-se em três indicadores: a complexidade ciclomática por módulo, a cobertura de testes automatizados e o tempo médio para incorporação de novas integrações externas. Para a medição da complexidade ciclomática, utilizou-se ferramenta específica. A cobertura de testes foi avaliada por ferramenta de cobertura, enquanto o tempo de integração foi examinado por ferramenta de análise de histórico de commits. Essas ferramentas permitiram a coleta contínua dos dados para aferir os atributos arquiteturais do sistema.
3. Resultados e Discussão
A investigação iniciou-se com a coleta e análise de 44 respostas de participantes, sendo 35 identificados como clientes e nove como prestadores de serviço. Essa segmentação dos dados foi crucial para uma análise diferenciada, permitindo a identificação de necessidades específicas e terminologias recorrentes em cada grupo. A análise lexical resultou na criação de dicionários representativos das expressões mais utilizadas, o que facilitou a identificação de termos relevantes, ações e objetos integráveis. Esses elementos serviram como base para o Mapeamento de Histórias e para a subsequente modelagem de software, alinhando o vocabulário dos usuários à modelagem técnica, conforme preconizado pelo Domain-Driven Design (Evans, 2004).
Os resultados para o perfil cliente revelaram padrões significativos sobre suas prioridades e preocupações. A análise dos termos mais frequentes (unigramas) nas respostas abertas destacou palavras como “prestador”, “serviço”, “agendamento”, “velocidade” e “pagamento”. Essa recorrência indicou um forte foco na conveniência, eficiência e qualidade na entrega dos serviços. A percepção de valor do sistema, por parte dos clientes, esteve intrinsecamente ligada à facilidade operacional, especialmente no que tange ao agendamento e pagamento, com uma ênfase notável na comunicação eficaz.
A análise de bigramas e trigramas para o perfil cliente reforçou esses achados. Termos compostos como “saber_dizer” e “encontrar_prestador” foram frequentemente citados, evidenciando a importância da comunicação clara e da facilidade em localizar prestadores. Similarmente, “prestador saber dizer” destacou-se entre os trigramas, sublinhando a necessidade de uma comunicação transparente e eficiente no processo de agendamento. A visualização por nuvem de palavras também confirmou a proeminência de “velocidade”, “prestador”, “agendamento”, “pagamento” e “serviço” no discurso dos clientes, indicando as associações mentais mais recorrentes.
A rede de coocorrência dos termos mais relevantes para os clientes demonstrou que “agendamento” e “pagamento” se conectavam a outras funcionalidades críticas, como “transporte”, “disponibilidade” e “prestador”. Essa interconexão apontou diretamente para as funcionalidades que os usuários finais consideravam essenciais para uma experiência satisfatória. Em relação às categorias de integração tecnológica desejada, os sistemas de agendamento foram os mais mencionados, seguidos pelos métodos de pagamento e, por fim, pelos serviços de transporte, refletindo as prioridades operacionais dos clientes.
Para o perfil prestador, a análise lexical também identificou termos recorrentes que expressaram suas necessidades e desafios operacionais. Palavras como “cliente”, “agendamento”, “pagamento” e “orçamento” foram as mais frequentes entre os unigramas. Esses termos indicaram preocupações primárias com a organização do trabalho, a previsibilidade dos agendamentos e a garantia da compensação pelos serviços prestados, elementos fundamentais para a gestão de suas atividades diárias.
Os bigramas e trigramas extraídos das respostas dos prestadores corroboraram a importância do agendamento e pagamento. Expressões compostas relacionadas a “pagamento” e “agendamento” foram as mais citadas, com destaque para “pagamento agendamento e realizar” entre os trigramas. Isso evidenciou que os prestadores focavam na execução eficiente e na conclusão financeira dos serviços. A nuvem de palavras para este grupo também realçou termos como “pagamento”, “agendamento” e “confirmação”, refletindo suas expectativas e experiências com sistemas integrados.
A rede de coocorrência para o perfil prestador revelou como os termos se organizavam semanticamente e sua relação com categorias tecnológicas desejadas, como notificações, transporte e pagamentos. O histograma de menções por categoria de integração tecnológica desejada pelos prestadores indicou que agendamento, métodos de pagamento e localização/deslocamento eram as categorias mais citadas, sublinhando a importância da integração com plataformas de rota ou transporte para otimizar suas operações.
A comparação entre os perfis de clientes e prestadores, juntamente com as capacidades de negócio extraídas por TF-IDF e as relações semânticas identificadas, subsidiou a construção de mapas de histórias específicos para cada ator (Patton, 2014). Para os clientes, as jornadas foram organizadas em torno de autenticação, agendamento, deslocamento e pagamento, evidenciando o fluxo de solicitação do serviço, acompanhamento e conclusão financeira. Para os prestadores, as jornadas focaram na autenticação, recebimento e confirmação de agendamentos, deslocamento e finalização do serviço com solicitação de pagamento, destacando a dimensão operacional da prestação.
Esses mapas de histórias permitiram transformar os achados léxicos em uma visão funcional do sistema, orientando a priorização do escopo do protótipo e a delimitação dos contextos. A análise de proximidade léxica e os eventos de domínio identificados, como “ServiçoSolicitado” e “PagamentoConfirmado”, foram fundamentais para essa delimitação. Os termos relacionados ao acesso e identificação dos atores formaram o contexto de Autenticação e Perfil, enquanto “agendar”, “confirmar” e “concluir” convergiram para Agendamento. Referências a localização e rota delinearam Logística, e “pagamento” e “transação” configuraram Pagamento.
Em nível estratégico, os contextos delimitados foram classificados conforme a taxonomia de Evans (2004) e Vernon (2016). O Agendamento foi definido como Domínio Central, representando a principal proposição de valor da plataforma, com lógica única de correspondência e gestão do ciclo do serviço. Autenticação e Perfil, e Logística foram classificados como Subdomínios de Suporte, essenciais, mas potencialmente substituíveis por soluções genéricas. Pagamento e Notificação foram considerados Subdomínios Genéricos, funcionalidades complexas, mas comuns, cuja estratégia ideal seria a integração com provedores especializados para minimizar o desenvolvimento interno.
A modelagem tática do protótipo organizou-se em torno de agregados e entidades de domínio explicitamente definidos, correspondendo aos conceitos identificados. O contexto de agendamento foi materializado no agregado “ServiceRequest”, centralizando o ciclo operacional da solicitação de serviço. O pagamento foi representado pela entidade “PaymentAttempt”, encapsulada no agregado para transições financeiras críticas, e externamente protegida por uma Camada Anticorrupção (ACL) via interface de “gateway” de pagamento. Os conceitos de usuário e prestador foram estruturados pelos agregados “User” e “ProviderService”, este último relacionado ao catálogo de serviços ofertados.
A logística e a notificação, embora relevantes na fase analítica, foram operacionalizadas no protótipo como integrações desacopladas do núcleo do sistema. A logística foi isolada por uma ACL, e a notificação encapsulada por interfaces e adaptadores de envio. Essa abordagem preservou a correspondência entre os conceitos analíticos e sua materialização no protótipo, garantindo que o modelo de domínio permanecesse íntegro e protegido das particularidades de sistemas externos, conforme enfatizado por Evans (2004) e Vernon (2016).
A validação arquitetural concentrou-se em três indicadores. A complexidade ciclomática por módulo, medida pela ferramenta Radon, indicou uma média global de 2,42 (grau A). A maioria dos módulos apresentou baixa complexidade estrutural, sugerindo uma decomposição satisfatória da solução em unidades coesas, em linha com as preocupações de Parnas (1972) sobre modularização. Pontos de concentração de complexidade foram observados em operações específicas de validação do domínio, como `ServiceRequest.validate()` (complexidade ciclomática de 71), `User.validate()` (complexidade ciclomática de 25) e `PaymentAttempt.validate()` (complexidade ciclomática de 26), indicando que a maior densidade de regras permaneceu concentrada nas invariantes centrais do domínio.
No que se refere à testabilidade, o relatório do pytest registrou 1.141 testes aprovados, com uma cobertura total de 99%. A distribuição da suíte de testes por camada revelou predominância na camada de domínio (595 testes, 52,10%), seguida pela camada de integração (386 testes, 33,80%) e API HTTP (160 testes, 14,00%). Essa distribuição, que concentrou validações de regras de negócio e invariantes na base e reforçou a camada intermediária de integração, mostrou-se compatível com a lógica de uma pirâmide de testes, adaptada ao problema arquitetural de mediação de serviços heterogêneos.
O tempo médio para incorporação de novas integrações externas, medido pelo PyDriller, forneceu insights sobre a capacidade evolutiva da arquitetura. A integração da ACL de logística levou 15,3 horas, enquanto o gateway de pagamento consumiu 60,3 horas. Outras integrações, como Email SMTP e notificações pós-operacionais, registraram 82,7 horas e 100,4 horas, respectivamente, e o JWT, 189,0 horas. Esses dados sugeriram que o padrão de Camadas Anticorrupção cumpriu seu papel de isolamento, controlando o impacto das dependências externas sobre o núcleo do domínio e reduzindo a contaminação semântica, conforme proposto por Evans (2004) e Vernon (2013).
A convergência entre os resultados qualitativos e os indicadores quantitativos constituiu o principal achado desta investigação. A Linguagem Ubíqua, construída a partir da análise lexical, orientou a delimitação dos contextos e a modelagem tática dos agregados. As métricas apuradas, como a baixa complexidade ciclomática média global de 2,42 e a alta cobertura de testes de 99%, demonstraram que a separação entre domínio, casos de uso e infraestrutura foi mantida. Os “cycle times” de integração, por sua vez, indicaram que o padrão ACL isolou efetivamente os serviços externos, mantendo o custo de incorporação circunscrito à camada de infraestrutura, sem propagação ao núcleo do domínio. Em conjunto, esses indicadores validaram empiricamente a hipótese de que a aplicação disciplinada dos princípios do Domain-Driven Design resultou em uma arquitetura mais modular, testável e evolutiva, capaz de gerenciar a complexidade das integrações heterogêneas.
4. Conclusão
O presente estudo investigou e avaliou a contribuição dos princípios do Domain-Driven Design (DDD) para a modelagem do domínio, a organização arquitetural e a integração de serviços heterogêneos em um sistema de conexão entre clientes e prestadores de serviços a domicílio. Para tanto, realizou-se um estudo de caso que envolveu o desenvolvimento de um protótipo funcional, cuja validação arquitetural se baseou em indicadores de complexidade ciclomática, cobertura de testes automatizados e tempo médio de incorporação de integrações externas. Verificou-se que a análise lexical das respostas dos participantes permitiu a construção de uma Linguagem Ubíqua, que orientou a delimitação de contextos e a modelagem tática de agregados, como o ServiceRequest para agendamento e o PaymentAttempt para transações financeiras. Os resultados quantitativos corroboraram esses achados, indicando uma baixa complexidade ciclomática média global de 2,42 e uma cobertura de testes de 99%, com predominância na camada de domínio. Observou-se que o padrão de Camadas Anticorrupção (ACL) isolou efetivamente os serviços externos, mantendo o custo de incorporação de novas dependências circunscrito à camada de infraestrutura, sem propagação ao núcleo do domínio. Essa abordagem demonstrou potencial para favorecer a modularidade, a testabilidade e a evolução incremental da solução, contribuindo significativamente para reduzir o impacto das integrações externas sobre a lógica de negócio central.
Contudo, a pesquisa apresentou limitações no escopo amostral, especialmente quanto ao número de prestadores de serviço, o que restringiu a consolidação da Linguagem Ubíqua no contexto logístico. Adicionalmente, o uso de simuladores (“mocks”) para pagamentos e logística delimitou os resultados a um ambiente controlado, sem as latências de APIs reais. Para pesquisas futuras, recomenda-se o foco na substituição desses simuladores por adaptadores reais e a realização de testes de escalabilidade em sistemas que operem com um volume maior de contextos, a fim de aprofundar a compreensão sobre a aplicabilidade e os benefícios do DDD em cenários de produção mais complexos.
Referências Bibliográficas
Avram, A.; Marinescu, F. 2006. Domain-Driven Design Quickly. Lulu Press, Raleigh, NC, USA.
Evans, E. 2004. Domain-Driven Design: Tackling complexity in the heart of software. Addison-Wesley, Boston, MA, USA.
Ford, N.; Parsons, R.; Kua, P. 2017. Building Evolutionary Architectures: Support constant change. O’Reilly Media, Sebastopol, CA, USA.
Newman, S. 2021. Building Microservices: Designing fine-grained systems. 2ed. O’Reilly Media, Sebastopol, CA, USA.
Parnas, D.L. 1972. On the criteria to be used in decomposing systems into modules. Communications of the ACM 15(12): 1053–1058. DOI: 10.1145/361598.361623.
Patton, J. 2014. User Story Mapping: Discover the whole story, build the right product. O’Reilly Media, Sebastopol, CA, USA.
Pressman, R.S. 2010. Engenharia de Software: Uma abordagem profissional. 7ed. AMGH, Porto Alegre, RS, Brasil.
Vernon, V. 2013. Implementing Domain-Driven Design. Addison-Wesley, Boston, MA, USA.
Vernon, V. 2016. Domain-Driven Design Distilled. Addison-Wesley Professional, Boston, MA, USA.
Artigo oriundo de Trabalho de Conclusão de Curso da Especialização em Engenharia de Software do MBA USP/Esalq
Para saber mais sobre o curso, clique aqui e acesse a plataforma MBX Academy
