Um bounded context é uma parte definida do software em que determinados termos, definições e regras se aplicam de forma consistente, explicou Eric Evans em sua palestra durante o DDD Europa no início deste ano. Um contexto canônico tem um modelo refinado e uma linguagem onipresente expressiva com definições não ambíguas. Mas a descrição de um sistema que parece tão arrumado é, para ele, muito suspeito. Nenhum dos grandes sistemas de software em que ele esteve envolvido tem estado em qualquer lugar perto dessa organização. Em uma apresentação recentemente publicada, ele descreve diferentes tipos de bounded contexts, incluindo alguns que envolvem microservices.
Eric Evans, um dos pensadores e líder sobre DDD e autor do livro referência Domain-Driven Design, observa que bounded context como um conceito atraiu crescente interesse da comunidade ao longo dos anos, mas ainda é uma área onde há mais a ser feito.
Uma confusão o qual Eric Evans às vezes percebe em equipes é a diferenciação entre contextos e subdomínios limitados. Em um mundo ideal, eles coincidem, mas, na realidade, estão freqüentemente desalinhados. Ele usa um exemplo de um banco estruturado em contas de dinheiro e cartões de crédito. Esses dois subdomínios no domínio bancário também são bounded contexts. Depois de reorganizar os negócios em torno de contas empresariais e contas pessoais, agora há dois outros subdomínios, mas os bounded contexts permanecem os mesmos, o que significa que agora estão desalinhados com os novos subdomínios. Isso geralmente resulta em duas equipes tendo que trabalhar nos mesmos bounded contexts, com um risco crescente de acabar com uma grande bola de lama.
Um contexto produtivo e maduro está produzindo valor, mas provavelmente baseado em conceitos no domínio central que estão desatualizados. Uma questão importante a ser feita é sobre o quanto o domínio central está desalinhado quando comparado com a visão atual do domínio central, e o quanto isso está restringindo a evolução dos negócios.
Muito desalinhamento pode levar a uma demanda na transformação do contexto existente, mas na experiência de Eric Evans, eles geralmente não se transformam tão bem. Alterar as suposições básicas do software geralmente significa que ele acabará não atendendo a necessidade do negócio; Por isso, ele não recomenda fazê-lo.
Outros tipos de contextos descritos por Eric Evans incluem o contexto Quaint, um contexto antigo que ainda assim realiza um trabalho útil, mas talvez seja implementado usando a tecnologia antiquada e não alinhada com a visão atual do domínio e o contexto de subdomínio genérico junto com contexto Generic Off the Shelf (OTS), que aborda um importante subdomínio genérico de uma forma convencional a que outros contextos devem obedecer. Ele também descreve e compara Contexto Generalista com Contexto Especialista.
Eric Evans acredita que os microservices são a maior oportunidade, mas também o maior risco que temos há muito tempo. O que devemos nos interessar mais é nas capacidades que eles nos dão para satisfazer as necessidades do negócio com o qual estamos trabalhando, mas ele também adverte contra o efeito bandwagon. Um problema que ele identifica é que muitos acreditam que um microservice é um contexto limitado, mas ele acredita que isso é uma simplificação excessiva. Em vez disso, ele identifica quatro tipos de contextos envolvendo microservices.
O primeiro é o tipo Service Internal, descrevendo como um serviço funciona. Para Eric Evans, esse é o tipo em que as pessoas pensam quando dizem que um microservice possui um contexto limitado. Neste caso, um serviço é isolado de outros serviços e gerenciado por uma equipe autônoma. Isso se encaixa em sua definição de um bounded context, mas ele observa que isso não é suficiente. Usando apenas esse tipo, acabamos com serviços que não sabem como falar uns com os outros.
O segundo tipo é o API of Service, descrevendo a comunicação com outros serviços. Um desafio aqui é como as equipes projetam e se adaptam a diferentes APIs. A direção do fluxo de dados pode determinar a dependência do desenvolvimento com os consumidores sempre em conformidade com um fluxo de dados upstream, mas Eric Evans acredita que existem alternativas. Grupos altamente influentes podem criar uma API à qual outros grupos devem obedecer, por exemplo, com o uso de algum tipo de autoridade, onde você geralmente deve se adaptar à suas APIs, independentemente da direção o qual os dados estarem fluindo.
O terceiro tipo é o Cluster de Serviços Codesigned. Este tipo, se refere ao cenário quando vários serviços são projetados para trabalhar uns com os outros com o objetivo de realizar algo, eles juntos formam um bounded context. Eric Evans observa que internamente, os serviços individuais podem ser bem diferentes com modelos diferentes do modelo usado na API.
O último e quarto tipo é o Interchange Context. Eric Evans ressalta que a interação entre os serviços também deve ser modelada. O modelo neste contexto descreve as mensagens e definições a serem usadas quando os serviços interagem com outros serviços. Ele observa que não há serviços nesse contexto; é tudo sobre mensagens, esquemas e protocolos.
Já o Legacy Asset exposto pode ser útil quando queremos que um sistema legado participe de um ambiente de microservices. Uma maneira é criar uma interface que se pareça com um microservice e interaja com outros microservices, mas interaja internamente com um sistema legado. Isso nos impede de corromper os novos microservices construídos, mas também nos impede de ter que mudar o sistema legado; eles são freqüentemente frágeis e podem ser corrompidos e até transformados em uma grande bola de lama.
Eric Evans conclui sua apresentação tentando definir o que realmente é DDD. Um desafio é quão bem o DDD deve ser definido. Uma definição deve compartilhar uma visão e linguagem comuns, mas também deve ser flexível para permitir a inovação e a melhoria. A comunidade é importante, mas deve ser uma comunidade honesta e aberta à possibilidade de estar errado quando o resultado não é o esperado. Ele também acredita que deveríamos tentar esclarecer os limites da aplicabilidade do DDD; Nem todos os projetos de software devem ser realizados com DDD.
Ele resume definindo o DDD como um conjunto de princípios orientadores: foco no domínio central, explorar modelos em uma colaboração criativa e falar uma linguagem onipresente dentro de um bounded context. Suas últimas palavras foram:
Vamos praticar o DDD juntos, chacoalhar e renovar.