das regras de negócio Tem a capacidade de traduzir o funcionamento do produto em organização. Não tem acesso a input/output Raramente domínios vão possuir views dentro deles. Evite a palavra Módulo, domínios não são módulos. Módulo possui muitos significados em diversos contextos, de linguagem, plataforma, frameworks, arquitetura, comercial...
Vida Namespaces garantem uma boa organização dos domínios. Composer permite criar pacotes para cada domínio, assim como seus relacionamentos/dependências.
Composer = Qualidade de Vida Projetos Laravel se adaptam muito bem a uma arquitetura baseada em domínios, é possível ir do mais simples, tendo apenas uma pasta a mais que contenha os domínios, até algo mais com complexo, modificando completamente estrutura de pastas iniciais. Ao iniciar um projeto Laravel você está apenas iniciando em seu boilerplate, Tudo ali pode ser modificado, não há amarras ou limitações.
depender do domínio ou das Unidades Domínio pode depender de Suporte, mas não das unidades Unidades podem depender de ambos suporte e Domínio http://bit.ly/2yCI70n
Simples de iniciar ❏ São baratos de se produzir ❏ Quase sempre única instância de servidor ❏ Difícil manter atualizado ❏ Castelo de cartas ❏ Com o tempo se tornam legados... ❏ Custa caro escalar ❏ Difíceis de manter por longos períodos
sente à vontade com o projeto. O custo inicial é baixo além de rapidamente mostrar resultados. Simples de colocar em produção e monitorar. Testes (quando existem) são caros. Com o tempo correções geram mais bugs, um ciclo vicioso de problemas. Manter atualizado pode ser impossível, pois os impactos podem ser imprevisíveis. Escalar é caro, não é simples separar processos em várias instâncias menores.
❏ Não fica preso a uma stack ❏ Permite centralização e reuso de operações ❏ Permite um melhor gerenciamento de recursos e custos ❏ Curva de adaptação e implementação elevada ❏ Exige bastante alinhamento da equipe ❏ Dependendo da stack e arquitetura possui latência considerável
um serviço cair ou ficar lento, não vai impactar toda a aplicação. Permite gerenciar com precisão os serviços mais vitais ou que consomem mais recursos. É um grande desafio, não há um “guia de boas práticas”. As referências do mercado geralmente são grandes de mais para serem seguidas ou possuem muitas particularidades. Inicialmente possui um custo muito elevado, que só se paga no médio-longo prazo.
que consomem outros serviços são comuns. Muitas vezes usa-se API-Gateways para facilitar o acesso aos serviços, além deles, ferramentas como GraphQL também ajudam a lidar com múltiplos serviços.
de Monolítico para Micro Serviços, é uma abordagem comum. Mover operações mais críticas ou mais pesadas para um Serviço ou API especializados trará, logo no início, um grande poder de escala.
não é simples, tal ação pode fragmentar as regras de negócio da aplicação. Para solucionar isso é possível usar o domínio como pacote, compartilhando ele entre o serviço e o monolítico.
estão complexas e amarradas que extrair essas regras beira o impossível. Para essas situações, encapsular o monolítico através de Micro Serviços é uma opção válida.
permita que eles fiquem presas a contextos de input/output. Seu controller é quem vai passar esses inputs e devolver os outputs, Ele é o responsável por isso, receber pedidos e devolver html, json, imagens...
suas aplicações de forma monolítica, ainda há valor nessa abordagem. Porém, com a evolução do seu produto, a necessidade de escala vai aparecer, nesse momento estará na noha de começar a usar Micro Serviços. Se a aplicação foi criada usando Domain Based, o custo dessa evolução será baixo.
Micro Serviços, porém não sabemos de fato como criar eles, e principalmente como criar eles de forma barata. Não somos a Netflix. A abordagem mais simples e trabalhar com Micro APIs, usando pacotes como domínios, compartilhando as regras de negócios comuns entre os serviços. Lembre-se, nem toda API é acessível externamente.
a possibilidade ou tempo para se usar Micro Serviços. Técnicas de escala ainda são úteis, além de truques como ter uma instância responsável por um grupo de requests. Mesmo sendo possível, evite essas abordagens.
em pacotes vantajoso por vários motivos. Vai facilitar manutenção, reuso e evolução do projeto. A camada Domains e Support são excelentes candidatos para essa abordagem.
vinicius73
suzushin54
yukimasa123
kymmt90
bassbone
chmikata
kuriko
rilmayer
oracle4engineer
star_zero
miyukki
grace2riku
ikumatadokoro
jlugia
pauljervisheath
phodgson
lara
orderedlist
paulrobertlloyd
morganepeng
62gerente
colly
lynnandtonic
shlominoach
jrom
