Somos contratados com a responsabilidade de colaborar com a construção de sistemas que estão inseridos dentro de um contexto de negócio, chamado: Domínio.

Operar em diferentes áreas ou nichos de negócio, comumente chamados de Domínio, faz parte do trabalho de qualquer pessoa técnica imergida no desenvolvimento sistemas, independente se está atuando no backend, arquitetura, ou UI. Ter o entendimento do setor no qual se está inserido, é essencial para que qualquer pessoa possa, minimamente, compreender os fluxos das informações e processos.

No primeiro artigo dessa série, foi explorada a importância da descoberta de sub-domínios dentro de um domínio e quais processos podem ser usados para ajudar a encontrar e entender o funcionamento do Business Flow (Fluxo de Negócio) de um determinado setor do mercado, no qual você está trabalhando.

Também, foram citados exemplos de setores do mercado, tais com:

• E-Commerce
• Tributação
• Educação
• Logística
• Saúde

Cada sub-domínio identificado dentro de cada um dos setores (domínios) acima, são classificados de Arquétipos.

O que são Arquétipos?

Segundo a filosofia, arquétipos são uma espécie de especialização sobre alguma coisa, ou sobre algum comportamento, ou sobre alguma entidade.

Através da perspectiva de Platão, temos o seguinte:

Apesar de ser tentador pensar nas Formas como entidades mentais (ideias) que existem apenas em nossa mente, o filósofo insistiu que elas são independentes de quaisquer mentes (atuais). As Ideias seriam coletivos no sentido de incorporarem as características fundamentais de uma coisa (qualidade universal).

Extrai-se dessa afirmação que devemos ter atenção ao contexto real de onde as coisas estão emergindo, sem o véu do achismo, compartilhando entendimento coletivo sobre como cada área dentro de um domínio funciona.

Entendendo conceitos essenciais

Saber diferenciar o que é um domínio de um sub-domínio, é a chave para o sucesso nessa fase de modelagem estratégica, considerando que a compreensão desses conceitos essenciais vai ajudar não só na identificação de áreas de responsabilidades, como também na organização das topologias dos times e delimitação de fronteiras de responsabilidades e conhecimentos distribuídos dentro das diversas unidades de negócio em uma empresa.

Existe uma grande confusão sobre o que é e como se deve trabalhar com domínios e sub-domínios. Além disso, é comum encontrar e ouvir colegas se referindo à sub-domínios como sendo domínios e vice-versa. - Não se preocupa com isso, porque eu também já cometi esse erro. Por isso escrevi esse post para te ajudar a entender os conceitos de forma correta 🙂.

Domínio

Um domínio refere-se a uma esfera de conhecimento, atividade ou interesse que é sujeita a modelagem. Também pode ser entendido como um setor de negócio.

O domínio define o contexto para o qual um software está sendo desenvolvido e aplicado. Assim sendo, um domínio é composto por conceitos, linguagens específicas, regras e processos que são relevantes para resolver os desafios apresentados por um determinado nicho de negócio.

Como já citado, no inicio desse post, domínios pode ser qualquer setor de negócio:

• Agricultura
• Saúde
• E-Commerce
• Logística
• Correios

O que diferencia um domínio do outro? Bem, isso vai depender de como cada proprietário de empresas, atuantes em um negócio específico, deseja resolver os desafios impostos pelas leis, regras e processos dentro do domínio que ele escolheu trabalhar.

No setor de Logística, por exemplo, existem vários desafios que podem ser enfrentados para gerir o tracking (acompanhamento) de encomendas e gestão de estoque.

Sub-domínio

Um "sub-domínio" é uma parte menor ou uma subdivisão do domínio principal. Ele pode representar uma área específica dentro do domínio maior ou um conjunto de conceitos especializados dentro do contexto desse sub-domínio.

Sub-domínios são úteis para organizar a modelagem para esse contexto específico, quando o domínio principal é grande ou complexo demais para ser tratado como único. Cada sub-domínio pode ter suas próprias regras, terminologias e especializações de processos.

Ainda podem existir casos em que um sub-domínio pode ganhar notoriedade entre os outros sub-domínios, tornando-se em um domínio propriamente dito, dentro de um domínio principal, tamanha a sua complexidade acumulada, tornando necessário aplicar, novamente, técnicas de descoberta de sub-domínios desse, que antes, era um sub-domínio.

Entendendo o domínio: Food Delivery

Todos nós somos contratados para desenvolver sistemas que estão inseridos em um contexto de negócio muito específico, por mais know-how (conhecimento) que você possa ter nessa área, haverá sempre uma oportunidade para enfrentar desafios novos.

Domain-Driven Design oferece ferramentas úteis e que nos dão o suporte necessário para trabalharmos os principais fundamentos da parte estratégica, criando modelagens que refletem a realidade de um setor de negócio, alinhando os contextos ao desenvolvimento do software que dará vida digital aos processos de uma empresa.

FoodDelivery será o domínio que utilizaremos durante toda a série de posts, guiando você sobre as técnicas e ferramentas adequadas, te ajudando a compreender como lidar com domínios e sub-domínios, contribuindo melhorar a organização e comunicação entre as unidades de negócio em projetos de software de uma empresa. Esse será o Moto dessa série.

Até aqui foram apresentadas muitas teorias! Mas como podemos descobrir e extrair esses processos?

No primeiro artigo, mencionamos várias técnicas úteis para descobertas de processos e sub-domínios, como Event Storming ou Domain Storytelling. Realizando workshops com um grupo reduzido de pessoas especialistas nas áreas importantes a serem debatidas, trabalhando a idealização do funcionamento desses fluxos de negócio.

Não se trata de nenhuma regra que te imponha chegar em uma organização propondo aplicar todas essas técnicas. Contudo, cedo ou tarde a aplicação dessas técnicas e ferramentas será não só útil, mas também necessária. Porém, inicialmente o que normalmente vai acontecer é que você será convidado para participar de rodadas de apresentações das necessidades de negócio da empresa. Algo similar ao diálogo simulado abaixo:

Estamos com a necessidade de criar uma plataforma como serviço que seja usada para realizar pedidos de refeições online. Essa plataforma vai cobrir desde o cadastro de um restaurante como parceiro até a entrega dos pedidos.

Também queremos disponibilizar promoções para os clientes dessa plataforma.

Outro serviço dessa plataforma, será um plano de assinatura, possibilitando os clientes a terem vantagens dentro da plataforma.

E também é preciso que se tenha um dashboard de acompanhamento de vendas por restaurante.

As informações acima podem gerar algum sentimento de desconforto, assumindo que a quantidade de pontos abordados é grande. Quero te dizer que você é uma pessoa com sorte, por ter esse privilégio de ter esses dados em mãos.

Muitas vezes, o que será solicitado à você será para 💥 refazer um sistema já existente ou criar um outro usando outras tecnologias, com base (literalmente falando) no sistema anterior, sem muita explicação e detalhes que poderiam te ajudar a levantar questões.

Então porque é que eu fico feliz com o compartilhamento dessa quantidade de informações? (Alguns poderão dizer o contrário, e achar que não tem muita informação, 🤷🏻). Bem, o momento de você começar a extrair detalhes, está por vir 🙂.

Vamos começar a destilar toda a informação que nos foi passada, começando por essa parte da conversa:

Estamos com a necessidade de criar uma plataforma como serviço que seja usada para realizar pedidos de refeições online. Essa plataforma vai cobrir desde o cadastro de um restaurante como parceiro até a entrega dos pedidos.

Inicialmente, você já toma conhecimento de uma informação muito importante: Criar uma plataforma SaaS para um FoodDelivery. Essa informação é bastante técnica para um inicio de conversa, mas esse contexto de aplicação detectado, favorece entender qual será o modelo de negócio, além de levantar outras perguntas: De que forma está se intencionando monetizar essa plataforma?

Agora vamos para a outra parte da conversa, e analisar mais informações:

Queremos disponibilizar promoções para os clientes dessa plataforma. Além de ter planos de assinatura, possibilitando os clientes a terem vantagens dentro da plataforma.

Fantástico! Algumas afirmações compartilhadas nessa parte da conversa, ajuda a identificar 2 macro-funcionalidades:

• Promoções serão criadas e disponibilizadas para os clientes da plataforma e potenciais novos clientes.
• Um programa de assinatura será criado e disponibilizado aos clientes, possibilitando aproveitar de benefícios para assinantes.

Esses dois temas identificados acima, vão te favorecer sobre a forma de direcionar o foco para a perspectiva do QUÊ será abordado em uma sessão aplicando Event Storming, por exemplo. Mas o nosso trabalho não para por aqui, e só está começando.

Ainda podemos levantar questões que precisam ser anotadas, afim de serem compartilhadas na sessão de workshop. Existem diferentes perguntas que uma pessoa poderia levantar:

• Como as promoções serão integradas nessa plataforma?
• Qual será o meio de veiculação dessas promoções? Email? Notificação no portal (aplicação)?
• Quando uma assinatura estiver perto de vencer, o que deve ser feito? Enviar uma promoção?
• Quando surgir um benefício associado a um plano, como notificar os clientes desse plano?

Essas foram algumas perguntas que podem ser anotadas e levadas para serem discutidas junto aos especialistas de negócio e pessoas envolvidas dentro dessa sessão de Workshop, afim de também contribuir com a construção desse produto. Não se esqueça de não só pensar nessas perguntas, mas também de tomar nota de todas elas.

Vamos analisar outra parte do contexto que nos foi compartilhado:

Quando um plano é contratado, o cliente receberá automaticamente o acesso ao sistema e a todos os benefícios desse plano, além de ser notificado sobre o contrato desse plano.

Até aqui, torna-se possível perceber algumas etapas de processos importantes que nos foram compartilhadas, e dentro desses processos estão contidas ações e eventos que vão dar suporte ao fluxo de negócio desenhado para atender às necessidades da empresa, como:

• Preparar as promoções de desconto
• Disponibilizar as promoções de desconto
• Preparação do contrato de assinatura do plano
• Pagamento do valor da assinatura
• Liberação de acesso

Ótimo! Agora já conseguimos extrair alguns processos e ações que vão ajudar durante a modelagem dos sub-domínios desse sistema. Mas ainda cabem algumas perguntas:

• Ao disponibilizar uma promoção, como será enviada ao cliente? Na App? Email?
• Se o cliente quiser usar essa promoção no restaurante físico, será possível? Como?

Se você chegou até essa parte do post, Parabéns! Você conheceu um processo de identificação de macro-funcionalidades, requisitos e aprendeu a explorar algumas questões importantes para enriquecer um workshop de descobertas e detalhamento de processos de negócio.

Agora um conselho que pode ficar aqui é: Utilize essas técnicas usadas durante esse processo de identificação, mas reuna todas as informações levantadas até aqui, de maneira estruturada, afim de te ajudar durante as sessões.

Conclusão

Durante a jornada desse post, cheio de conceitos e abordagens que auxiliam na descoberta de informações necessárias para o desenvolvimento de qualquer sistema ou até mesmo de uma funcionalidade, buscou mostrar a importância de se ter como ferramenta um processo de trabalho objetivo, facilitando a comunicação das pessoas especialistas no negócio, construindo um produto digital consistente.

Reunir as pessoas adequadas dentro de sessões de descobertas, ajuda no entendimento dos fluxos de negócio que estão sendo pensados e desejados, e que serão catalizadores para se ter uma movimentação para o digital, de forma coerente com que está sendo necessário para uma organização.

📌 No próximo post vamos começar a usar esses conhecimentos e partir para um quadro 📋 de descoberta de sub-domínios 😃.

Referências

• https://www.eventstorming.com/
• https://pt.wikipedia.org/wiki/Arquétipo