Resumo Executivo

Alvaro Souza e Silva; Lucas José de Souza

Resumo elaborado pela ferramenta ResumeAI, solução de inteligência artificial desenvolvida pelo Instituto Pecege voltada à síntese e redação.

Vivemos em uma era caracterizada por volumes massivos de dados e informações, na qual organizações de diversos setores investem pesadamente em tecnologias voltadas para a produção, coleta, gerenciamento e análise desses ativos (Francisco et al., 2019). Grande parte desse montante informacional pode conter dados sensíveis que, se expostos ou utilizados de forma inadequada, comprometem a privacidade e a segurança de indivíduos ou instituições (Figueiredo, 2022). Entretanto, existe uma vasta gama de dados não sensíveis que permanecem subexplorados e que poderiam ser compartilhados e integrados por meio de Interfaces de Programação de Aplicações, conhecidas como APIs. O compartilhamento e a integração desses dados fortalecem significativamente os ecossistemas de inovação, permitindo que empresas e indivíduos coevoluam a partir de ações contínuas de cooperação e coparticipação (Gomes et al., 2024). A disponibilização de dados via API favorece a interoperabilidade com agentes externos e proporciona novas perspectivas sobre as informações, gerando ideias que impactam positivamente a sociedade e as organizações através de processos de reutilização de dados (Tavares et al., 2024).

A geração de inovação está intrinsecamente ligada à criação de produtos ou processos novos ou aprimorados que diferem significativamente de versões anteriores e que são disponibilizados para usuários ou colocados em uso interno (OECD, 2018). No contexto tecnológico, a inovação de produto refere-se a bens ou serviços introduzidos no mercado, enquanto a inovação de negócio envolve processos aprimorados em funções empresariais. Um exemplo prático dessa dinâmica é observado na empresa Valve, que disponibiliza a Steam Web API para garantir acesso a funcionalidades do Steamworks, auxiliando a comunidade na integração e criação de jogos. Essa iniciativa permitiu o surgimento de inovações como a plataforma OpenDota, que coleta, organiza e categoriza dados do jogo Dota 2, tornando-os acessíveis e compreensíveis para o público. Contudo, muitas APIs não são planejadas para suportar grandes volumes de usuários ou ciclos constantes de atualização, resultando em domínios pouco expressivos, códigos acoplados e dificuldades de escalabilidade.

Para mitigar esses problemas técnicos e conceituais, a adoção do Domain-Driven Design apresenta-se como uma abordagem eficaz, focando a modelagem do software em torno da lógica do domínio do negócio (Evans, 2014). O domínio compreende o problema do mundo real que o software visa resolver, englobando suas regras, processos e conceitos fundamentais. Ao criar um modelo de domínio rico e expressivo, garante-se que o software reflita com precisão a área de atuação, o que é essencial para o sucesso de sistemas complexos e de longo prazo. A aplicação dessa metodologia no desenvolvimento de APIs públicas visa promover clareza e facilitar a construção de soluções inovadoras por parte de desenvolvedores externos. Para demonstrar a viabilidade dessa proposta, utiliza-se como exemplo um domínio de jogo do tipo RPG, focando em expor catálogos de itens e gerenciar leilões, ocultando dados sensíveis de contas e funcionalidades administrativas.

A fundamentação teórica do design orientado a domínio estabelece que a complexidade do software deve ser enfrentada no coração do sistema: o seu domínio. Quando uma API pública é construída sem essa preocupação, a barreira de entrada para novos desenvolvedores aumenta, pois a semântica dos endpoints e dos dados retornados pode ser confusa ou desconectada da realidade do negócio. Ao aplicar os princípios de design estratégico e tático, busca-se uma estrutura que não apenas funcione tecnicamente, mas que também sirva como uma documentação viva e intuitiva do ecossistema que ela representa. Assim, a justificativa para a criação de um template padronizado reside na necessidade de reduzir a lacuna entre a intenção do provedor de dados e a interpretação do consumidor, potencializando o surgimento de novos modelos de negócio e aplicações derivadas.

A metodologia adotada nesta investigação é de natureza aplicada, concentrando-se na estruturação e validação de um template para o desenvolvimento de Web APIs públicas fundamentadas nos conceitos de design orientado a domínio. O processo operacional iniciou-se com a definição de um domínio de exemplo, optando-se pelo universo de jogos RPG. A escolha desse domínio justifica-se pela sua riqueza de regras e pela familiaridade que muitos desenvolvedores possuem com seus conceitos. O ambiente tecnológico para a construção do template incluiu a linguagem CSharp, utilizando o framework .NET 8, que oferece robustez e alta performance para aplicações modernas. Para a persistência de dados, selecionou-se o MongoDB, um banco de dados não relacional que permite flexibilidade na modelagem de documentos complexos, enquanto o Entity Framework Core atuou como o mapeador objeto-relacional para a comunicação entre a aplicação e a base de dados.

O desenvolvimento do template seguiu etapas rigorosas de design estratégico. A primeira fase consistiu na identificação e designação de especialistas de domínio, responsáveis por fornecer o conhecimento necessário para a modelagem. Por meio de reuniões iterativas e processamento contínuo de conhecimento, a equipe de engenharia e os especialistas definiram o domínio principal como sendo o Jogo RPG, focado em um mundo fictício onde jogadores controlam personagens e interagem com itens. Dentro desse contexto, foram delimitados dois subdomínios essenciais: o Catálogo de Itens, destinado à consulta de armas, armaduras e consumíveis, e a Casa de Leilões, responsável por gerenciar a compra e venda de itens entre os jogadores. Essa divisão clara de responsabilidades é fundamental para manter a coesão do sistema e facilitar futuras expansões.

A etapa subsequente envolveu a construção da Linguagem Ubíqua, um pilar central da metodologia proposta por Evans (2014). Foram estabelecidos termos comuns e consistentes que devem ser utilizados tanto no código-fonte quanto na documentação e nas interações entre a equipe. Termos como Itens, Atributos, Raridade, Instância do Item, Loja e Classe de Personagem foram minuciosamente definidos. Por exemplo, a Raridade foi categorizada em níveis como Comum, Raro, Épico e Único, cada um com implicações específicas na disponibilidade e valor do objeto. A Classe de Personagem foi delimitada a tipos tradicionais como Guerreiro, Ladino, Mago, Druída, Clérigo e Bruxo. Essa padronização terminológica reduz drasticamente a ocorrência de mal-entendidos e garante que a API seja expressiva para qualquer desenvolvedor que possua o conhecimento básico do domínio.

Após a consolidação da linguagem, procedeu-se à identificação das entidades e objetos de valor. No subdomínio de Catálogo de Itens, a entidade Item foi definida por atributos como identificador único, nome, descrição, tipo, raridade e valor de venda. Já a Instância de Item representa a cópia específica possuída por um jogador, contendo uma lista de atributos variáveis como dano, defesa ou vida. No subdomínio da Casa de Leilões, as entidades Leilão e Lance foram estruturadas para suportar o fluxo de negociações, incluindo prazos, preços iniciais e status de ativação. Os objetos de valor, caracterizados por serem imutáveis e desprovidos de identidade própria, incluíram conceitos como Dinheiro (composto por valor decimal e tipo, como ouro, prata ou bronze) e Atributo do Item.

A documentação de design foi elaborada utilizando diagramas de classes e de fluxo para esclarecer os conceitos do modelo e orientar o estilo de uso da aplicação. O diagrama de classes representou a estrutura estática, modelando as relações de herança, associação e agregação entre as entidades e objetos de valor. Paralelamente, os diagramas de fluxo detalharam os processos operacionais, como a criação de um novo registro de item, a abertura de um leilão e a submissão de um lance. No fluxo de registro de leilão, por exemplo, foram estabelecidas validações críticas: a existência do personagem, a verificação se o anunciante é o proprietário legítimo da instância do item e se o preço inicial é inferior ao preço de compra imediata. Para o registro de lances, as validações incluíram o status ativo do leilão, a suficiência do valor ofertado em relação ao lance atual e a restrição de que o anunciante não pode dar lances em seu próprio leilão.

Para a validação do template e mensuração de seus benefícios, aplicou-se um questionário eletrônico a um grupo de 13 desenvolvedores de software, selecionados em comunidades profissionais. Os participantes tiveram acesso a documentos gerados via Swagger, disponibilizados em ambiente de nuvem, que descreviam a API construída com base no template. O instrumento de coleta de dados conteve oito questões, abrangendo o perfil dos respondentes, sua experiência prévia com APIs externas e suas percepções sobre a clareza, facilidade de integração e potencial inovador da proposta. A análise utilizou escalas de Likert de 1 a 5, onde 1 representava discordância total ou dificuldade máxima e 5 representava concordância total ou facilidade máxima. O versionamento do código foi mantido no GitHub e as ferramentas Draw.io e Excalidraw foram utilizadas para a modelagem visual, garantindo a transparência e a reprodutibilidade do estudo.

Os resultados obtidos revelam um perfil diversificado entre os 13 respondentes, o que confere robustez à análise das percepções coletadas. Em termos de senioridade, a amostra contou com seis profissionais de nível Sênior, cinco de nível Pleno e dois de nível Júnior, indicando uma representação equilibrada de diferentes estágios da carreira no desenvolvimento de software. A quase totalidade dos participantes confirmou trabalhar ou já ter trabalhado diretamente com o desenvolvimento de aplicações, o que assegura que as opiniões emitidas possuem fundamento na prática profissional cotidiana. Além disso, 12 dos 13 respondentes afirmaram já ter consumido APIs externas em condições de documentação escassa ou endpoints pouco intuitivos, evidenciando que a problemática abordada é recorrente no mercado.

Ao avaliar a percepção de dificuldade na integração com APIs externas convencionais, observou-se um cenário de equilíbrio: 50% dos participantes classificaram a experiência como fácil ou muito fácil, enquanto os outros 50% dividiram-se entre a neutralidade e a percepção de dificuldade. Esse dado é relevante pois demonstra que, mesmo para profissionais experientes, a integração com sistemas cujos domínios são opacos pode gerar frustrações e demandar um esforço cognitivo elevado. Em contrapartida, ao serem expostos à documentação da API baseada no template de design orientado a domínio, 46% dos respondentes avaliaram a integração como razoavelmente fácil ou fácil. Embora 15% tenham considerado a experiência desafiadora, é importante notar que a ausência de notas máximas de facilidade pode ter sido influenciada pelo acesso limitado à documentação completa, uma vez que os participantes interagiram apenas com arquivos estáticos e não com um ambiente de execução dinâmico.

A análise da concordância sobre o potencial de geração de ideias inovadoras apresentou uma tendência amplamente positiva. A maioria dos participantes situou suas respostas entre os níveis 3, 4 e 5 da escala de Likert, reconhecendo que a forma como a API foi estruturada facilita o entendimento sobre o domínio de atuação e, consequentemente, estimula a criatividade para o desenvolvimento de novas soluções. Esse resultado corrobora a premissa de que uma modelagem ubíqua e expressiva atua como um catalisador para a inovação, permitindo que o desenvolvedor foque na lógica de valor da nova aplicação em vez de gastar tempo decifrando a semântica básica dos dados fornecidos. O template demonstrou ser capaz de tornar a API mais clara e inspiradora, promovendo uma melhor assimilação dos conceitos de negócio.

Um dos achados mais significativos refere-se à capacidade de ideação imediata: 69,2% dos respondentes indicaram que a leitura dos materiais e da documentação da API contribuiu para o surgimento de novas possibilidades de aplicação. Apenas 30,8% afirmaram não ter identificado esse potencial de imediato. Esse alto índice de geração de ideias reforça a eficácia do uso de subdomínios bem definidos e de uma linguagem compartilhada. Ao explorar cenários criativos, os desenvolvedores conseguiram ampliar sua compreensão sobre como os dados do catálogo de itens e da casa de leilões poderiam ser reaproveitados em contextos diversos, como ferramentas de análise de mercado para jogadores ou aplicativos auxiliares de inventário. Entretanto, o percentual de respostas negativas sugere que, para alguns perfis, o material disponibilizado ainda poderia ser mais detalhado ou conter exemplos de uso mais robustos.

A discussão dos dados à luz da literatura técnica indica que a aplicação do design orientado a domínio em APIs públicas reduz a lacuna entre as perspectivas técnica e de negócios, conforme preconizado por Evans (2014). A clareza semântica observada no template permitiu que mesmo desenvolvedores que não participaram da modelagem original conseguissem navegar pela estrutura de forma lógica. A utilização de entidades e objetos de valor bem definidos proporcionou uma base sólida para a interoperabilidade, facilitando a reutilização de dados mencionada por Tavares et al. (2024). Além disso, a estrutura proposta mostrou-se resiliente às complexidades inerentes a sistemas de alta demanda, sugerindo que a adoção dessas práticas pode levar a um ciclo de vida de software mais sustentável e menos propenso a efeitos inesperados durante atualizações.

Apesar dos resultados positivos, é necessário reconhecer as limitações do estudo. O tamanho reduzido da amostra, composta por 13 indivíduos, impede a generalização estatística dos resultados para toda a comunidade de desenvolvedores. Além disso, o foco em um único domínio de exemplo, o RPG, pode não refletir as dificuldades específicas de áreas de negócio com regras ainda mais abstratas ou regulamentações rígidas. Outro ponto de atenção é que a avaliação baseou-se em uma percepção pontual de documentação, sem a realização de testes de integração em tempo real, o que poderia revelar desafios técnicos adicionais não captados pelo questionário. Sugere-se que pesquisas futuras expandam a aplicação do template para domínios variados, como finanças ou saúde, e utilizem amostras maiores para validar a eficácia da abordagem em diferentes contextos organizacionais.

A implicação prática deste estudo para a engenharia de software é a confirmação de que o investimento em modelagem de domínio não deve ser restrito ao núcleo interno das aplicações, mas deve transbordar para as suas interfaces públicas. APIs expressivas funcionam como pontes para a inovação aberta, permitindo que agentes externos contribuam para o ecossistema de forma mais ágil e assertiva. A redução da barreira de entendimento inicial é um diferencial estratégico para empresas que desejam que seus dados sejam amplamente adotados e transformados em novos produtos ou serviços. O template proposto oferece um roteiro claro para atingir esse objetivo, equilibrando o rigor técnico com a clareza conceitual necessária para fomentar a coevolução nos ecossistemas de inovação contemporâneos.

Conclui-se que o objetivo foi atingido, uma vez que o template baseado em Domain-Driven Design demonstrou ser uma ferramenta eficaz para promover a clareza e a expressividade em Web APIs públicas, facilitando o entendimento do domínio e estimulando a geração de ideias inovadoras entre desenvolvedores de diferentes níveis de senioridade. A análise dos dados confirmou que a estruturação de subdomínios e o uso de uma linguagem ubíqua reduzem as barreiras de integração e potencializam a criação de novas soluções tecnológicas, embora a eficácia plena da abordagem dependa de uma documentação detalhada e do acesso a ambientes de teste robustos. A iniciativa apresenta-se como uma contribuição relevante para a área de engenharia de software, oferecendo um modelo prático que pode ser adaptado para diversos contextos de negócio, visando sempre a qualidade técnica e o valor estratégico das aplicações desenvolvidas.

Referências Bibliográficas:

Afonso Tavares, André; Müller Bitencourt, Caroline; Da Silva Cristóvam, José Sérgio. Api’s De Natureza Pública E Sua Relevância Para Promoção Da Inovação E Concretização Da Interoperabilidade Na Administração Pública. Administração de Empresas em Revista, [S.l.], v. 4, n. 37, p. 349 – 389, dez. 2024. ISSN 1676-9457. Disponível em: <https://revista.unicuritiba.edu.br/index.php/admrevista/article/view/7490>. Acesso em: 01 abr. 2025.

Evans, E. 2014. Domain-driven design : tackling complexity in the heart of software. Boston, Mass. ; Munich: Addison-Wesley

Figueiredo, D. Proteção de privacidade de dados em ambiente de big data analytics: um estudo da realidade brasileira. 8 dez. 2022.

Francisco, E. D. R. et al. Beyond Technology: Management Challenges In The Big Data Era. Revista de Administração de Empresas, v. 59, n. 6, p. 375–378, dez. 2019.

Gomes, C.; Machado, P.; Ferreira, R. Panorama de pesquisas sobre ecossistemas de inovação: Ciência da Informação, v. 53, 18 jul. 2024.

OECD/Eurostat (2018), Oslo Manual 2018: Guidelines for Collecting, Reporting and Using Data on Innovation, 4th Edition, The Measurement of Scientific, Technological and Innovation Activities, OECD Publishing, Paris. Acesso em: 4 jun. 2025.

Resumo executivo oriundo de Trabalho de Conclusão de Curso de MBA em Engenharia de Software

Saiba mais sobre o curso, clique aqui