Get best of the week

Projetando um contexto delimitado com uma tela de contexto vinculado: receita do workshop

Entre os tópicos da próxima conferência TechLead Conf 2020 , haverá uma discussão detalhada sobre Design Orientado a Domínio e EventStorming. Além de preparar um relatório de dois slots de Konstantin Gustov no DDD , um relatório de Sergey Baranov no EventStorming e uma mitap durante a qual criaremos um radar de DDD, decidimos traduzir um artigo sobre um dos métodos mais populares para projetar contexto limitado.

Como dividir um sistema grande em componentes menores e mais gerenciáveis? Muitas vezes me fazem essa pergunta, então reuni meu conhecimento neste artigo.

No DDD, um grande sistema é decomposto em contextos limitados (comentário de um tradutor: daqui em diante serão chamados de contextos limitados) , que se tornam limites naturais - como microsserviços no código e como equipes em uma organização.

Não há como determinar rápida e facilmente os bons limites de um contexto limitado. Isso requer um conhecimento extenso e profundo dos negócios e da área de assunto. Este formato de workshop foi projetado para atender a essas duas necessidades e usa duas ferramentas para encontrar o design de sistema mais eficaz: EventStorming e Bounded Context Canvas.

imagem

“Desenvolvi essa tela no processo de realização de workshops sobre DDD em eventos públicos e sessões corporativas. Sinta-se livre para alterar sua estrutura se encontrar os formatos mais adequados para você. ”

Receita


A receita principal consiste no seguinte:

  1. EventStorming (mínimo de 1 hora).
  2. Modelagem de candidatos para um contexto limitado (mínimo de 30 minutos).
  3. Modelando o fluxo de mensagens de domínio (pelo menos 30 minutos).
  4. Tela de contexto limitada (mínimo 90 minutos).
  5. Criando mapas contextuais (pelo menos 45 minutos).

Como ponto de partida, recomendo alocar um dia inteiro para este workshop. Isso o ajudará a entender quanto tempo você realmente precisa para realizar o workshop corretamente. Se for caro (demorado) reunir todos, tente alocar imediatamente dois dias para concluir tudo.

Idealmente, os participantes devem ser especialistas no assunto e técnicos. Se isso for difícil de organizar, tente garantir que os especialistas em domínio estejam no workshop por pelo menos a primeira hora.

Princípios básicos de modelagem


Para realizar uma sessão com especialistas, você precisa de uma sala espaçosa. Se você escolher um público pequeno, provavelmente ficará desapontado com os resultados. Cada grupo de 4 pessoas precisará de pelo menos 4 metros na parede.

Descreverei minha metodologia de forma livre, sem regulamentos estritos. No entanto, lembre-se:
“Estamos constantemente alternando entre o espaço do problema e o espaço da solução. "Estamos procurando informações, criando um modelo, procurando informações adicionais, atualizando o modelo etc."
E outro ponto importante: o objetivo da sessão é desenvolver opções e desenvolver a capacidade de oferecer melhores opções no futuro.

1. EventStorming


Para projetar um sistema, você precisa de duas coisas: uma idéia geral suficientemente boa de todo o sistema e uma compreensão bastante profunda dos detalhes em cada área. Para fazer isso, vamos começar com EventStorming .

O EventStorming é um método de design colaborativo que permite simular uma grande área de problemas do início ao fim e também permite que você faça uma busca detalhada de um grande número de peças, quando necessário.

imagem

Se for a primeira vez que você faz isso, recomendo que você reserve 1-2 horas no EventStorming. Depois de concluir o EventStorming, recomendo dividir em grupos de 4 pessoas.
No TechLead Conf 2020, Sergey Baranov falará sobre a experiência prática com o EventStorming .

2. Procure candidatos para um contexto limitado


Depois que seu domínio for modelado de maneira ampla e profunda no EventStorming, você poderá começar a agrupar e mesclar fragmentos em um contexto limitado.

imagem

Existem muitos métodos para determinar o contexto limitado. Eu recomendo começar com o seguinte:

  • Comece com valor - identifique as partes principais do domínio que são mais valiosas para os negócios.
  • Comece com um simples - crie um modelo ingênuo dividindo a linha do tempo em etapas sucessivas.
  • Procure os principais eventos - eventos de negócios que afetam diferentes partes do processo de negócios.

Pela primeira vez, não gaste mais de 30 minutos nessa tarefa. Convide o grupo para criar o modelo de contexto limitado original como ponto de partida. Não precisa ser perfeito e é improvável que seja a solução final.

A saída deve estar em uma lista de nomes de contexto limitados em um flipchart ou papel. Você não pode modificar fisicamente o EventStorming se tiver vários grupos.

Próximos passos


Você pode ver imediatamente várias maneiras de modelar o sistema. Por enquanto, escolha um deles para o trabalho e anote outros possíveis modelos (eles serão úteis mais tarde). Você também pode entender que estão faltando informações de domínio. Nesse caso, faça outra rodada do EventStorming.

3. Modelando o Fluxo de Mensagens do Domínio


Uma maneira de validar seu design e procurar pontos de melhoria é visualizar a interação de contextos limitados em cenários completos de sistemas de negócios.

Se o fluxo do domínio for complexo, com um grande número de dependências e conexões bidirecionais, seu design será frágil e precisará de mais análises.

Existem muitos métodos de visualização que podem ser usados ​​para modelar fluxos e casos de uso, incluindo diagramas de sequência UML e diagramas de casos de uso UML. Eu recomendo usar a opção de contar histórias no domínio .

Ao modelar o fluxo de mensagens de um domínio de assunto, contextos limitados são os atores da história. Assim, uma história típica começa com o usuário tentando alcançar algum objetivo, e a interação entre contextos limitados visa fornecer uma solução ao usuário.

imagem
Um exemplo fictício de um fluxo de mensagens de domínio A

modelagem de fluxos de domínio estratégico permite obter feedback sobre os contextos limitados propostos. Ele mostra como os contextos colaboram entre si e dependem um do outro para concluir um processo de negócios completo. Isso pode ajudar a encontrar um design alternativo.

A pergunta que você deve fazer é se a descrição de cada contexto limitado corresponde à função que ela desempenha no fluxo do domínio. Caso contrário, é provável que os limites de nome ou contexto exijam reprojeto.

Próximos passos


Como os fluxos do seu domínio determinam o relacionamento entre contextos limitados, é possível detectar imediatamente falhas óbvias no design. Você pode voltar à ação anterior e atualizar os candidatos para um contexto limitado ou executar uma segunda iteração do EventStorming. Você também pode anotar seus pensamentos sobre design e coletar mais informações sobre as próximas etapas antes de iniciar o novo design.

4. Tela de Contextos Limitados


O próximo estágio do design é o desenvolvimento de candidatos para um contexto limitado, usando detalhes dos principais critérios de design. Sua equipe deve escolher o contexto limitado que você considera mais importante. Limite a discussão a no máximo 3 minutos. Não é essencial ter 100% de precisão.

Agora desenhe uma tela de contexto limitada e siga estas etapas para preencher os detalhes. Eu recomendo o uso de 1 folha de flipchart ou papel do mesmo tamanho.
Depois de concluir essas etapas, repita o processo até identificar todos os seus contextos limitados. Tente dividir seu tempo igualmente entre os candidatos identificados para um contexto limitado.

4.1 Definição do contexto geral


Comece definindo o nome do seu contexto delimitado e sua descrição. A descrição deve mostrar a finalidade do contexto no domínio e sua função nos negócios, e não os detalhes da implementação.

Em seguida, você precisa fazer uma classificação estratégica. O contexto limitado é a parte principal do sistema, um elemento auxiliar, um elemento comum ou algo mais? Leia o post de Vlad se precisar de ajuda para escolher.

imagem
Como exemplo, uma tela de contexto encadernada preenchida após a 1ª etapa.

Próximos passos


Se você não conseguir criar um nome claro, ou escrever uma descrição coerente e precisa, ou seus termos para Linguagem Ubíqua (UL) forem ambíguos, considere isso como feedback para o seu design. Considere redesenhar as bordas ou tome uma nota e volte mais tarde (geralmente é melhor voltar mais tarde).

4.2 Esclarecimento das regras de negócios e formação de uma linguagem comum


Agora volte ao EventStorming e observe as notas para este contexto limitado. Encontre as regras e políticas comerciais mais importantes, tente selecionar as 3 mais importantes e adicioná-las à tela.
Konstantin Gustov, do TechLead Conf 2020 , falará sobre seus muitos anos de experiência com o Ubiquitous Language e outros componentes DDD em Raiffeisen.
Este também é um bom momento para procurar palavras-chave ou frases-chave da empresa para adicioná-las à tela na seção Idioma Ubíquo. Você continuará adicionando palavras e frases ao longo do workshop, agora esse é apenas o ponto de partida.

imagem

4.3 Análise de recursos


O próximo passo é explorar as possibilidades fornecidas pelo contexto delimitado. Isso não apenas esclarece o que ele está fazendo, mas também fornece muito feedback para o design. Você pode fazer perguntas como:

  • Esse contexto está sobrecarregado de responsabilidades?
  • As oportunidades parecem relacionadas?
  • Os recursos correspondem ao nome e à descrição do contexto?
  • E se tirarmos essa oportunidade de contexto?

Comece a definir oportunidades introduzindo uma interface pública. O que os consumidores podem solicitar desse contexto limitado e quais comandos eles podem chamar? Use fluxos de dados do domínio para ver o que os consumidores precisam desse contexto limitado.

Nem todos os recursos são ativados por comandos e solicitações externas. Alguns recursos podem ser lançados de dentro. Por exemplo, tarefas agendadas. Às vezes, você pode perceber que as oportunidades estão agrupadas, por exemplo, um comando, solicitação e notificação. Nesse caso, coloque-os juntos na tela e dê um nome ao cluster.

Você pode sentir que a responsabilidade é inadequada e deve estar relacionada a outro contexto limitado. Nesse caso, selecione-o com algum tipo de marca de identificação no adesivo.

imagem

Próximos passos


Se você achar difícil determinar os recursos de contexto ou achar que alguns deles estão faltando, recomendo retornar ao EventStorming e modelar esse contexto limitado em mais detalhes, com foco em encontrar os recursos necessários para outros contextos ou serviços.

Aprofundando os recursos [opcional]


Disponha todas as oportunidades em sua tela para obter recursos adicionais. Este detalhe adicional o ajudará a encontrar modelos alternativos. Se não houver espaço suficiente na tela para as peças, encontre outra folha de papel ou espaço na parede. Você pode ir quantas camadas mais profundas achar melhor.

4.4 Dependências


Dependências são necessárias se queremos modularidade, mas também causam uma ampla gama de problemas comerciais, técnicos e sociais. Portanto, é importante ver as dependências, entender sua influência e considerar opções alternativas. E, portanto, a última etapa no design de um contexto limitado é garantir que você capture todas as principais dependências do seu contexto limitado.

Examinando os resultados do EventStorming e os diagramas de fluxo do domínio, identifique cada dependência que possui um contexto limitado e anote as seguintes informações:

  • o nome de outro contexto ou serviço limitado;
  • Uma breve explicação de por que existe vício
  • onde está a dependência: dentro deste sistema ou em um sistema externo (por exemplo, um serviço de terceiros);
  • tipo de relacionamento: esta é uma dependência recebida (outro serviço depende desse contexto limitado), de saída (esse contexto limitado depende de outro), bidirecional ou interface do usuário (a dependência é algum tipo de interface do usuário).

Questione cada uma das dependências: se é necessário, quais são os custos e benefícios de sua disponibilidade. Se parecer que você pode ficar sem ele, marque a dependência com um adesivo amarelo.

imagem

4.5 Críticas construtivas


Quando você concluir o preenchimento da tela, reserve alguns minutos para avaliar criticamente o design resultante do seu contexto delimitado. Divida seus comentários nas seguintes categorias:

  • Bom : projete os aspectos que você gosta.
  • Ruim : aspectos de design que você não gosta.
  • Incerto : aspectos de design dos quais você não tem certeza.

4.6 Reflexão e repetição


Um bom design é iterativo. Antes de passar para o próximo contexto delimitado, dê um passo para trás e veja a imagem geral. Você aprendeu algo que é contrário ao seu design? Nesse caso, cruze os limites propostos e continue projetando o próximo contexto delimitado.

Neste ponto, pergunte-se se o domínio está modelado com detalhes suficientes. Foi difícil preencher algumas partes da tela? Nesse caso, tente outra rodada do EventStorming em todo o domínio ou em algumas partes dele.

5. Criando mapas de contexto


Depois de criar uma tela para cada contexto delimitado e coletar comentários sobre o design, a próxima parte da sessão é um retorno à exploração. Desta vez, você tem um conjunto completo de conhecimentos que o ajudarão a encontrar as melhores opções de design.

O resultado deste exercício é uma coleção de mapas de contexto básicos - visualizações dos relacionamentos estruturais entre contextos limitados e quaisquer outros diagramas que você considere necessários, como diagramas de fluxos de domínio. Cada equipe deve desenvolver pelo menos três mapas de contexto, cada um deles mostrando as opções possíveis para a construção do sistema.

imagem
Um exemplo de um mapa de contexto muito preciso, para este workshop é suficiente.

Realizaremos um resumo na TechLead Conf 2020, onde analisaremos as várias técnicas, padrões e antipadrões do DDD e coletaremos um radar visual. Que será publicado após a conferência.
A atividade final pode ser realizada de forma livre. O objetivo é revisar as informações coletadas e usá-las para desenvolver vários designs de sistema. Como ponto de partida, eu recomendo:

  • Veja todas as avaliações coletadas para cada contexto e experimente as revisões "ruins" e "inseguras".
  • Faça perguntas "e se" ...
  • "E se transferirmos essa oportunidade para outro contexto limitado?"
  • "E se quebrarmos essa oportunidade e movermos uma das subfunções para outro contexto limitado?"
  • "E se dividirmos o contexto limitado em vários contextos?"
  • "E se aproveitarmos uma oportunidade de cada um desses três contextos e a usarmos em um novo contexto?"
  • "E se duplicarmos a funcionalidade para remover o vício?"
  • "E se criarmos um serviço comum para reduzir a duplicação em diferentes contextos?"
  • "E se isolarmos oportunidades realmente importantes e mudarmos o restante para um lugar mais pacífico, em um contexto separado?"

Se você preferir visualizar essas transformações, as seguintes ilustrações podem ser úteis:

imagem

imagem

imagem

Encerramento da oficina


Para concluir a sessão, cada grupo deve apresentar uma seleção dos mapas de contexto que eles criaram e discutir as compensações de cada design. Você precisa explicar sua escolha, pois isso geralmente é suficiente para uma apresentação de 5 a 10 minutos.

O que você precisa considerar na apresentação:

  • : .
  • : .
  • , , .

- TechLead Conf 8 9 . 32 , , , , DDD .

- — ( , ). , .

More articles:


All Articles