Traga clareza para o seu monólito com contextos delimitados
confira o vídeo desta palestra a partir de ElixirConf 2017 abaixo
as aplicações monolíticas são ótimas quando você começa a construir sua empresa, mas à medida que o tempo avança, elas se tornam difíceis de manter. Estas codebases, à medida que crescem, tornam-se facilmente grandes bolas de lama.
ao construir grandes aplicações em frameworks como trilhos, os princípios de design de Convenção-sobre-configuração que fizeram Rails uma alegria tão grande de usar começam a ficar no caminho quando a aplicação cresce em escopo. Você pode estar sofrendo as mesmas dores, bem como se:
- Refatoração é difícil e tedioso, porque métodos e classes dependem de muitas outras classes
- Você tem uma lista cada vez maior de objetos de negócios que são difíceis de manter em sua cabeça. Na verdade, ninguém parece ser capaz de entender o sistema como um todo coeso
- Alterar código em uma área de código leva inesperados e indesejados efeitos colaterais em outras áreas do código, porque é fácil para chamar a atenção da global serviços e objetos
- vamos falar de domínios
- Contextos limitados no espaço de solução
- the big idea: Organize Rails code into modules by business subdomain
- inverter as estruturas de pastas num agrupamento orientado para o domínio plano
- modulize classes
- Referência associado modelos por completo nome da classe
- Manter controladores atualizado sobre onde encontrar o seu recém-modulized vistas
- o Que funciona bem com esta abordagem?
vamos falar de domínios
um princípio fundamental no DDD é que o software que você constrói deve espelhar de perto o domínio (de negócios) da organização que o constrói. Assim, precisamos fazer alguns trabalhos de casa para entender o domínio de negócios de seu software.
um domínio é o que o negócio faz, e o contexto de como ele o faz.
vamos revisitar o nosso exemplo Delorean do post anterior. Nela, a empresa é comercializada como Uber para viagens no tempo. Assim, seu “domínio” (o “o que ele faz”) é a partilha de viagens no tempo. Também incluído no domínio está o “como” de como ele faz – por parceria motoristas que possuem veículos Delorean viagem no tempo com passageiros que querem fazer viagens no tempo.
para obter mais nuances no domínio de negócios, DDD introduz outro conceito, chamado de subdomínio:
um subdomínio representa os pequenos grupos ou unidades do negócio que colaboram no dia-a-dia para alcançar os objetivos do negócio.
Delorean está dividido em várias equipes dentro da empresa. Vamos ver dois deles, e ver do que são responsáveis.:
| Viagem da equipe da Plataforma | Finanças equipe de Operações | |
|---|---|---|
| Missão | Design e suporte a sistemas de rota de viagens e ligar drivers para os passageiros | Gerir os sistemas que envolvem instituições financeiras e processadores de cartão de crédito |
| Responsabilidades |
|
|
cada um destes dois grupos anima uma responsabilidade empresarial, ou subdomínio. Vamos chamá-los de experiência de partilha e Comércio Eletrônico, respectivamente.
agora temos uma ilustração geral do negócio e duas de suas unidades que o ajudam a funcionar no dia-a-dia. O domínio e subdomínio são formas de modelar o espaço problema de seu negócio – e como ele age para cumprir esses papéis. É provável que o seu organigrama de negócios reflicta de perto os subdomínios do seu negócio. No mundo real, as delineações podem ser menos claras-as equipas podem ser responsáveis por sub-domínios múltiplos e sobrepostos.
vamos preencher este diagrama com mais alguns subdomínios no negócio Delorean:
- subdomínio do apoio Ao Cliente: resolução de bilhetes de Apoio ao cliente que chegam através de E-mail
- subdomínio do Marketing: gestão de marketing, campanhas de e-mail marketing e códigos de cupom
- Identidade subdomínio: Como o sistema de faixas de cada usuário e de sua informação de identificação
Contextos limitados no espaço de solução
um contexto limitado é um sistema que cumpre os objetivos do negócio no mundo real.
qualquer um dos nossos sistemas de software (como um serviço web ou aplicativo web) que operam como instâncias concretas no mundo Real são considerados contextos limitados.Tecnicamente falando, o contexto limitado em DDD-speak é um limite específico dentro do seu domínio que o seu glossário de sua linguagem onipresente só pode aplicar – a ideia é que diferentes subdomínios podem ter definições concorrentes ou conflitantes de termos. Este post não vai elaborar sobre as nuances linguísticas do contexto limitado. For further reading, see Martin Fowler’s explanation on Bounded Contexts.
agora acontece que em Delorean, todos esses subdomínios são implementados em um sistema – Uma Grande Bola de Mud Rails Monólito. Vamos desenhar uma caixa azul em torno dos sub-domínios cujas funções são implementadas pelo sistema de software. Neste caso, começaremos com o nosso Monólito Rails.:
uma vez que é o monólito, ele basicamente faz tudo – e então aqui, ele está comendo todos os outros subdomínios no diagrama.
não esqueçamos-temos alguns outros sistemas de software que não modelamos aqui. E todas as boas integrações de terceiros que a empresa usa? Estes também são sistemas de software. Vamos desenhá-los como caixas azuis.
a propósito, o que elaboramos aqui está um Mapa de Contexto – um diagrama que mistura objetivos de negócios e implementações concretas de sistemas de software. É útil para avaliar o layout da terra de seus sistemas de software e visualizar dependências entre equipes.
agora, isso é razoável e limpo, mas nós vivemos no mundo real, e o software do mundo real raramente sai parecendo consistente e coerente. Se você construiu seu aplicativo Rails seguindo suas convenções fora da Caixa, seu aplicativo internamente carece dos agrupamentos necessários para visualizar seu aplicativo em seus componentes constituintes. Na realidade, a base de dados Delorean parece-se mais com isto.:
O ponto – Rails não impõe qualquer organizacional restrições em nossos sistemas de software, o que significa que as unidades de negócios lógico (nossos subdomínios) que sugerem dissociado interfaces – não são materializado no código, levando a confusão e complexidade crescente com o passar dos anos.
the big idea: Organize Rails code into modules by business subdomain
Even though your Ruby classes in your application probably live in the global namespace, they can easily be plucked into modules. Nosso objetivo é criar grupos lógicos de código de domínio que possam ser isolados em componentes AUTO-contidos.
de fato, um dos objetivos dos projetos de domínio é ter um mapeamento de um para um de um subdomínio para um contexto limitado.O que significa isto? Vamos entrar em algumas recomendações, junto com exemplos.
inverter as estruturas de pastas num agrupamento orientado para o domínio plano
pode lembrar-se que a seguir às convenções de Rails nos leva a hierarquias de pastas que agrupam classes por papéis:
vamos mover tudo para uma nova estrutura de directórios: vamos agrupar funcionalidade por domínio, em vez disso. Vamos começar com uma primeira variação, que eu chamarei de agrupamento de domínio plano.
modulize classes
em seguida, você vai querer modulizar as classes a partir do que eram antes. Uma vez que a classe de controladores é abrangida pelo domínio de partilha de pacotes, adicioná-lo-emos a um módulo de partilha de pacotes:
irá querer fazer isto para cada classe que passar para a estrutura de directórios planos app/domains.
Referência associado modelos por completo nome da classe
Manter controladores atualizado sobre onde encontrar o seu recém-modulized vistas
agora, nós fizemos alguns pequenos passos para alcançar clareza arquitetônica em nossa aplicação. Se olharmos, agora, a nossa modular estruturas de pasta nos ajudaram agrupados nosso código assim:
Sob o capô, o nosso aplicativo pode parecer mais como este:
o Que funciona bem com esta abordagem?
- Há menos ruído em cada diretório de arquivo – por agrupamento de arquivos por domínio, a especificidade, encontramos um natural organizacional
- As entidades que permanecem em cada domínio da pasta, são altamente coesivo – o mais provável é que, naturalmente, tendem a se comunicar uns com os outros e aparecem naturalmente uns com os outros
- Entidades que não pertencem juntos estão agora separados (mais flexível-juntamente)
- Se você tem equipes de engenharia que trabalhar junto Subdomínio-responsabilidades, esses engenheiros agora podem trabalhar de uma forma mais simplificada, de modo isolado. Menor acoplamento permite que essas equipes para fazer alterações com a confiança de que eles não vão introduzir regressões ou conflitos de mesclagem de volta para a base de código
- O palco já está definido, a longo prazo, para começar a mover cada uma dessas pastas de domínio em um software independentes de serviço (mais sobre isso em um futuro post de blog)
Se você quiser alguma orientação adicional para esta estrutura de pasta, eu desenvolvi um aplicativo de exemplo que apresenta este domínio orientada a estrutura de pasta: http://github.com/andrewhao/delorean. Dá uma vista de olhos e diz-me o que achas.O que aprendemos?
no nosso tempo juntos, aprendemos sobre conceitos de design baseados no domínio em torno de Domínios e subdomínios. Aprendemos a visualizar nossos sistemas de software como contextos limitados em um mapa de contexto, que nos mostrou as áreas do sistema que pertencem juntas como partes coerentes.
terminando numa nota prática, ilustrámos como os ficheiros e pastas dos carris podem ser “invertidos” e reimaginados como primeiros agrupamentos do domínio.
no meu próximo post, vamos continuar a nossa discussão em um próximo post no blog sobre como dissociar ainda mais o nosso código de trilhos orientado para o domínio com eventos de domínio, e eventualmente fazer o nosso caminho para a terra dos micro-serviços.
