Introdução e conceitos básicos sobre Domain Driven Design (DDD) com foco na solução de problemas do universo de desenvolvimento de software, focando no core business do software a ser desenvolvido
O documento apresenta os conceitos e arquitetura do Design Orientado a Domínio (DDD). Ele explica que DDD é uma abordagem de desenvolvimento de software focada nas regras de negócio e no domínio, não nos bancos de dados. O documento também descreve artefatos como entidades, objetos de valor, agregações, serviços e repositórios.
Domain-Driven Design - Uma Abordagem Introdutóriaarmeniocardoso
Domain-Driven Design (DDD) é uma abordagem para desenvolvimento de software que estabelece forte ligação entre implementação e modelo de negócios. DDD fornece estrutura de práticas e terminologia para tomada de decisões de design, focando em acelerar projetos de software e alinhar com domínios de negócio. DDD utiliza conceitos como modelagem orientada a domínio, arquitetura em camadas, entidades, value objects, aggregates, services e repositories.
A análise e modelagem de software não é uma atividade simples, quando o domínio do software não é algo trivial e mais complicado ainda. O Domain Driven Design sugere uma nova abordagem para resolver estas tarefas, criando uma linguagem única para todas as pessoas envolvidas no projeto.
Nesta palestra buscamos conhecer um pouco mais sobre essa abordagem e quais ferramentas temos para aplicá-la utilizando PHP.
O documento apresenta os conceitos e princípios do Domain-Driven Design (DDD), uma abordagem de modelagem de software orientada ao domínio de negócio. Descreve padrões como entidades, objetos de valor, serviços e repositórios de domínio para modelar o núcleo de negócio. Também apresenta princípios como linguagem ubíqua e contextos de domínio bem delimitados para garantir que o modelo de domínio capture adequadamente as regras e complexidades do negócio.
Domain-Driven Design não é uma tecnologia ou metodologia. DDD é uma abordagem à modelação de software que providencia uma estrutura de práticas, padrões de programação e terminologias que ajudam à sua concepção.
Nesta sessão vamos conhecer o que é Domain-Driven Design, quando o usar e como implementar.
1. O documento apresenta Rodrigo Branas, palestrante e instrutor de Domain-Driven Design.
2. Ele tem formação em Ciências da Computação e Gerenciamento de Projetos e trabalhou com grandes empresas.
3. Domain-Driven Design é abordado, focando na importância de entender profundamente o domínio do negócio através da linguagem ubíqua e do modelo de domínio.
Esquenta TDC - Como DDD e principalmente Domain Model contribuem na construçã...Isaac de Souza
O documento discute como aplicar Domain-Driven Design (DDD) na construção de microservices, enfatizando a importância de se desenvolver um modelo de domínio para orientar a fragmentação em serviços e garantir a coerência entre os contextos.
O documento discute os princípios do Domain-Driven Design (DDD), abordando como entender o domínio de um software, desenhar um modelo efetivo e implementar uma arquitetura orientada a domínio. O DDD foca em regras de negócio complexas, baixo acoplamento e independência de tecnologia através de boas práticas como modelagem do domínio, linguagem ubíqua, entidades, objetos de valor, agregados, serviços, repositórios e fábricas.
O documento apresenta os conceitos e arquitetura do Design Orientado a Domínio (DDD). Ele explica que DDD é uma abordagem de desenvolvimento de software focada nas regras de negócio e no domínio, não nos bancos de dados. O documento também descreve artefatos como entidades, objetos de valor, agregações, serviços e repositórios.
Domain-Driven Design - Uma Abordagem Introdutóriaarmeniocardoso
Domain-Driven Design (DDD) é uma abordagem para desenvolvimento de software que estabelece forte ligação entre implementação e modelo de negócios. DDD fornece estrutura de práticas e terminologia para tomada de decisões de design, focando em acelerar projetos de software e alinhar com domínios de negócio. DDD utiliza conceitos como modelagem orientada a domínio, arquitetura em camadas, entidades, value objects, aggregates, services e repositories.
A análise e modelagem de software não é uma atividade simples, quando o domínio do software não é algo trivial e mais complicado ainda. O Domain Driven Design sugere uma nova abordagem para resolver estas tarefas, criando uma linguagem única para todas as pessoas envolvidas no projeto.
Nesta palestra buscamos conhecer um pouco mais sobre essa abordagem e quais ferramentas temos para aplicá-la utilizando PHP.
O documento apresenta os conceitos e princípios do Domain-Driven Design (DDD), uma abordagem de modelagem de software orientada ao domínio de negócio. Descreve padrões como entidades, objetos de valor, serviços e repositórios de domínio para modelar o núcleo de negócio. Também apresenta princípios como linguagem ubíqua e contextos de domínio bem delimitados para garantir que o modelo de domínio capture adequadamente as regras e complexidades do negócio.
Domain-Driven Design não é uma tecnologia ou metodologia. DDD é uma abordagem à modelação de software que providencia uma estrutura de práticas, padrões de programação e terminologias que ajudam à sua concepção.
Nesta sessão vamos conhecer o que é Domain-Driven Design, quando o usar e como implementar.
1. O documento apresenta Rodrigo Branas, palestrante e instrutor de Domain-Driven Design.
2. Ele tem formação em Ciências da Computação e Gerenciamento de Projetos e trabalhou com grandes empresas.
3. Domain-Driven Design é abordado, focando na importância de entender profundamente o domínio do negócio através da linguagem ubíqua e do modelo de domínio.
Esquenta TDC - Como DDD e principalmente Domain Model contribuem na construçã...Isaac de Souza
O documento discute como aplicar Domain-Driven Design (DDD) na construção de microservices, enfatizando a importância de se desenvolver um modelo de domínio para orientar a fragmentação em serviços e garantir a coerência entre os contextos.
O documento discute os princípios do Domain-Driven Design (DDD), abordando como entender o domínio de um software, desenhar um modelo efetivo e implementar uma arquitetura orientada a domínio. O DDD foca em regras de negócio complexas, baixo acoplamento e independência de tecnologia através de boas práticas como modelagem do domínio, linguagem ubíqua, entidades, objetos de valor, agregados, serviços, repositórios e fábricas.
O documento discute conceitos de análise e projeto orientados a objetos, incluindo identificação de classes, herança, encapsulamento, polimorfismo, UML e projeto orientado a objetos visando baixo acoplamento e alta coesão.
O documento discute aspectos do projeto de software durante a fase de construção. Ele aborda tópicos como: 1) a diferença entre projeto em projetos pequenos e grandes, onde muitas atividades são consideradas parte da construção em projetos menores; 2) como lidar com a complexidade no projeto, minimizando a complexidade para o programador; e 3) os diferentes níveis de projeto, desde o sistema como um todo até métodos individuais.
O documento discute dois tópicos: (1) Paradigma de Orientação a Objetos, introduzindo seus conceitos-chave como objeto, classe e encapsulamento; (2) Persistência de dados via JDBC, explicando os tipos de drivers JDBC e fornecendo um exemplo básico de uso do JDBC.
Indo além do técnico para desenvolver sistemas que evoluem na velocidade do...Taller Negócio Digitais
Se já viu ou ouviu falar dos temidos sistemas legados sabe que modificar ou acrescentar novas funcionalidades são tarefas complexas ou inviáveis recorrendo a famosa e muito utilizada técnica de refazer tudo do zero com a esperança de que desta vez o software responda na mesma velocidade que o negócio evolui. E mesmo aplicando as “boas práticas” com o passar do tempo o resultado é o mesmo, um sistema complexo repleto de abstrações que não fazem sentido pro negócio.
Nesta palestra vou te mostrar abordagens e ferramentas do Domain Driven Design (DDD) que vão te ajudar a construir sistemas de maneira colaborativa com o pessoal que entende do negócio junto com quem é mais técnico (Devs, UX, …) para que o sistema reflita o negócio e evolua de acordo com a velocidade do negócio.
A importância de DDD e o Domain Model na construção de APIs!Isaac de Souza
O documento discute a importância de aplicar Domain-Driven Design (DDD) na construção de APIs, especificamente: (1) Modelar o domínio do negócio com entidades e contextos claros; (2) Usar uma linguagem universal consistente nos contratos da API; (3) Construir a API como uma camada separada da implementação, focada no negócio.
O documento discute o Domain Driven Design (DDD), uma abordagem de desenvolvimento de software focada no domínio do negócio. O DDD envolve uma colaboração próxima entre especialistas de negócio e desenvolvedores para construir um design rico que reflita o domínio sem complexidades técnicas desnecessárias. O documento também apresenta alguns conceitos-chave do DDD como objetos de valor, entidades, agregados e serviços.
O documento fornece uma introdução ao Active Directory, comparando ambientes com e sem ele. Explica que o Active Directory permite a centralização e organização segura de informações de usuários, grupos e computadores de uma rede. Ele também resume os principais componentes do Active Directory, incluindo florestas, árvores, domínios, sites e unidades organizacionais.
Higher order functions, currying, recursion, map, filter, pattern matching e fold são técnicas funcionais discutidas. O documento também discute princípios do Domain-Driven Design como alinhamento de código com negócio, reutilização, desacoplamento e independência de tecnologia. É explicado que DDD foca no domínio, não no banco de dados, e que a camada de domínio é o coração do software.
Domain-Driven Design (DDD) é uma abordagem para desenvolvimento de software focada no domínio do negócio e na lógica de negócio. DDD torna a programação mais divertida ao libertar os desenvolvedores da dependência do banco de dados, focar no entendimento do cliente e separar claramente as responsabilidades do código. Classes de negócio como entidades, agregações, serviços e repositórios ajudam a definir um modelo coerente e compreensível do domínio.
1) O documento discute Domain Driven Design (DDD), uma abordagem para projeto de software focada no domínio e suas regras de negócio.
2) DDD utiliza conceitos como linguagem ubíqua, modelagem dirigida por domínio e blocos de construção como entidades, agregados e serviços.
3) O documento também apresenta técnicas como refatoração e mapas de contexto para lidar com sistemas complexos.
Este documento discute os principais conceitos do Domain-Driven Design (DDD), incluindo:
1) DDD é focado na redução da complexidade de software através da compreensão do domínio do negócio e da criação de modelos expressivos.
2) Os subdomínios são decompostos e os contextos delimitados mapeiam como cada parte será implementada tecnicamente.
3) Os modelos de domínio representam a lógica e regras de negócio de cada subdomínio.
Tentar empregar DDD em sistemas legados, geralmente é decepcionante. Então iremos mostrar algumas estratégias para tentar fazer isso acontecer e apontar algumas realidades que podem acontecer.
E se você não sabe o que é DDD, não fique preocupado, pois essa palestra não é sobre Domain Driver Design. Apesar de comentarmos fortemente sobre, iremos dar um norte para futuramente você se aprofundar.
O documento discute os principais conceitos do Domain Driven Design (DDD), incluindo: 1) O foco do DDD é no domínio e na lógica do domínio; 2) Os modelos no DDD são abstrações baseadas no domínio; 3) Entidades, objetos de valor, agregações e serviços são conceitos importantes no DDD.
O documento resume os principais conceitos do Domain Driven Design (DDD). Ele explica que DDD é uma abordagem focada no domínio e na lógica de negócios, utilizando modelos baseados no domínio e uma linguagem ubíqua compartilhada. Também descreve conceitos-chave como entidades, agregações, serviços, repositórios e o ciclo de vida de objetos no DDD.
O documento discute os princípios de código limpo, incluindo: (1) código limpo deve ser eficiente e ter lógica direta para minimizar bugs, (2) deve ter poucas dependências, e (3) deve ser legível para facilitar manutenção. Ele também fornece dicas como usar nomes significativos e formatar código claramente.
1) O documento descreve como o Domain Driven Design (DDD) e o Strategic Design estão ajudando a modernizar um legado de sistema para uma empresa de medicina do trabalho.
2) O sistema começou simples mas cresceu de forma desorganizada ao longo de 5 anos, levando a muitos bugs. O DDD está sendo usado para dividir o domínio em Bounded Contexts e melhorar a arquitetura.
3) A estratégia envolve isolar funcionalidades em módulos/libs, definir interfaces para comunicação com o legado, e
Este documento apresenta conceitos de código limpo em exemplos de código. Apresenta quatro partes: uma sobre filosofia, outra sobre teoria, outra sobre prática em exemplos de código e uma sobre laboratório de refatoração. Apresenta conceitos como DDD, SRP, DRY, testes, refatoração e regras de simplicidade aplicados em exemplos de código.
O documento discute o framework Naked Objects, que facilita a construção de aplicações orientadas a objetos a partir de objetos comportamentalmente completos. O framework fornece mecanismos de visualização e persistência que refletem automaticamente o modelo de objetos, poupando esforços do desenvolvedor. A abordagem promove sistemas verdadeiramente orientados a objetos e mais flexíveis às mudanças de requisitos.
O documento discute conceitos de análise e projeto orientados a objetos, incluindo identificação de classes, herança, encapsulamento, polimorfismo, UML e projeto orientado a objetos visando baixo acoplamento e alta coesão.
O documento discute aspectos do projeto de software durante a fase de construção. Ele aborda tópicos como: 1) a diferença entre projeto em projetos pequenos e grandes, onde muitas atividades são consideradas parte da construção em projetos menores; 2) como lidar com a complexidade no projeto, minimizando a complexidade para o programador; e 3) os diferentes níveis de projeto, desde o sistema como um todo até métodos individuais.
O documento discute dois tópicos: (1) Paradigma de Orientação a Objetos, introduzindo seus conceitos-chave como objeto, classe e encapsulamento; (2) Persistência de dados via JDBC, explicando os tipos de drivers JDBC e fornecendo um exemplo básico de uso do JDBC.
Indo além do técnico para desenvolver sistemas que evoluem na velocidade do...Taller Negócio Digitais
Se já viu ou ouviu falar dos temidos sistemas legados sabe que modificar ou acrescentar novas funcionalidades são tarefas complexas ou inviáveis recorrendo a famosa e muito utilizada técnica de refazer tudo do zero com a esperança de que desta vez o software responda na mesma velocidade que o negócio evolui. E mesmo aplicando as “boas práticas” com o passar do tempo o resultado é o mesmo, um sistema complexo repleto de abstrações que não fazem sentido pro negócio.
Nesta palestra vou te mostrar abordagens e ferramentas do Domain Driven Design (DDD) que vão te ajudar a construir sistemas de maneira colaborativa com o pessoal que entende do negócio junto com quem é mais técnico (Devs, UX, …) para que o sistema reflita o negócio e evolua de acordo com a velocidade do negócio.
A importância de DDD e o Domain Model na construção de APIs!Isaac de Souza
O documento discute a importância de aplicar Domain-Driven Design (DDD) na construção de APIs, especificamente: (1) Modelar o domínio do negócio com entidades e contextos claros; (2) Usar uma linguagem universal consistente nos contratos da API; (3) Construir a API como uma camada separada da implementação, focada no negócio.
O documento discute o Domain Driven Design (DDD), uma abordagem de desenvolvimento de software focada no domínio do negócio. O DDD envolve uma colaboração próxima entre especialistas de negócio e desenvolvedores para construir um design rico que reflita o domínio sem complexidades técnicas desnecessárias. O documento também apresenta alguns conceitos-chave do DDD como objetos de valor, entidades, agregados e serviços.
O documento fornece uma introdução ao Active Directory, comparando ambientes com e sem ele. Explica que o Active Directory permite a centralização e organização segura de informações de usuários, grupos e computadores de uma rede. Ele também resume os principais componentes do Active Directory, incluindo florestas, árvores, domínios, sites e unidades organizacionais.
Higher order functions, currying, recursion, map, filter, pattern matching e fold são técnicas funcionais discutidas. O documento também discute princípios do Domain-Driven Design como alinhamento de código com negócio, reutilização, desacoplamento e independência de tecnologia. É explicado que DDD foca no domínio, não no banco de dados, e que a camada de domínio é o coração do software.
Domain-Driven Design (DDD) é uma abordagem para desenvolvimento de software focada no domínio do negócio e na lógica de negócio. DDD torna a programação mais divertida ao libertar os desenvolvedores da dependência do banco de dados, focar no entendimento do cliente e separar claramente as responsabilidades do código. Classes de negócio como entidades, agregações, serviços e repositórios ajudam a definir um modelo coerente e compreensível do domínio.
1) O documento discute Domain Driven Design (DDD), uma abordagem para projeto de software focada no domínio e suas regras de negócio.
2) DDD utiliza conceitos como linguagem ubíqua, modelagem dirigida por domínio e blocos de construção como entidades, agregados e serviços.
3) O documento também apresenta técnicas como refatoração e mapas de contexto para lidar com sistemas complexos.
Este documento discute os principais conceitos do Domain-Driven Design (DDD), incluindo:
1) DDD é focado na redução da complexidade de software através da compreensão do domínio do negócio e da criação de modelos expressivos.
2) Os subdomínios são decompostos e os contextos delimitados mapeiam como cada parte será implementada tecnicamente.
3) Os modelos de domínio representam a lógica e regras de negócio de cada subdomínio.
Tentar empregar DDD em sistemas legados, geralmente é decepcionante. Então iremos mostrar algumas estratégias para tentar fazer isso acontecer e apontar algumas realidades que podem acontecer.
E se você não sabe o que é DDD, não fique preocupado, pois essa palestra não é sobre Domain Driver Design. Apesar de comentarmos fortemente sobre, iremos dar um norte para futuramente você se aprofundar.
O documento discute os principais conceitos do Domain Driven Design (DDD), incluindo: 1) O foco do DDD é no domínio e na lógica do domínio; 2) Os modelos no DDD são abstrações baseadas no domínio; 3) Entidades, objetos de valor, agregações e serviços são conceitos importantes no DDD.
O documento resume os principais conceitos do Domain Driven Design (DDD). Ele explica que DDD é uma abordagem focada no domínio e na lógica de negócios, utilizando modelos baseados no domínio e uma linguagem ubíqua compartilhada. Também descreve conceitos-chave como entidades, agregações, serviços, repositórios e o ciclo de vida de objetos no DDD.
O documento discute os princípios de código limpo, incluindo: (1) código limpo deve ser eficiente e ter lógica direta para minimizar bugs, (2) deve ter poucas dependências, e (3) deve ser legível para facilitar manutenção. Ele também fornece dicas como usar nomes significativos e formatar código claramente.
1) O documento descreve como o Domain Driven Design (DDD) e o Strategic Design estão ajudando a modernizar um legado de sistema para uma empresa de medicina do trabalho.
2) O sistema começou simples mas cresceu de forma desorganizada ao longo de 5 anos, levando a muitos bugs. O DDD está sendo usado para dividir o domínio em Bounded Contexts e melhorar a arquitetura.
3) A estratégia envolve isolar funcionalidades em módulos/libs, definir interfaces para comunicação com o legado, e
Este documento apresenta conceitos de código limpo em exemplos de código. Apresenta quatro partes: uma sobre filosofia, outra sobre teoria, outra sobre prática em exemplos de código e uma sobre laboratório de refatoração. Apresenta conceitos como DDD, SRP, DRY, testes, refatoração e regras de simplicidade aplicados em exemplos de código.
O documento discute o framework Naked Objects, que facilita a construção de aplicações orientadas a objetos a partir de objetos comportamentalmente completos. O framework fornece mecanismos de visualização e persistência que refletem automaticamente o modelo de objetos, poupando esforços do desenvolvedor. A abordagem promove sistemas verdadeiramente orientados a objetos e mais flexíveis às mudanças de requisitos.
3. FORMA DE DIMINUIR A COMPLEXIDADE
DO CORAÇÃO DO SISTEMA
resolver o problema do negócio
resolver a parte principal do sistema
4. utiliza diversos design patterns, mas não está
acoplado a nenhum
Não se trata apenas de criar camadas, entidades,
repositórios etc
Design guiado pelo domínio (razão da aplicação
existir)
8. DOMÍNIO
o coração do negócio (razão do negócio existir)
tem base em um conjunto de ideias, conhecimento
e processos
sem domínio, os processos auxiliares não tem muita
utilidade
9. PARA RESOLVER O PROBLEMA DE
NEGÓCIO, NÃO PRECISAMOS
NECESSARIAMENTE DE CÓDIGO
Mas sim...
10. COMUNICAÇÃO
conseguir falar com todos os envolvidos em uma
mesma linguagem
conversar entre todas as áreas, com todos os
envolvidos no problema
11.
12. LINGUAGEM UBÍQUA
é a linguagem falada no dia a dia no contexto da
empresa
utiliza as terminologias da realidade do negócio
desenvolvedores precisam conhecer a fundo a
linguagem do negócio
objetivo: conseguir modelar o sistema para
representar o negócio real
13. LINGUAGEM UBÍQUA
Exemplo: O que é "Cliente"?
quem loga no sistema?
quem compra algum produto?
quem contrata um serviço?
23. identificar quais são as partes do domínio principal
identificar quais são os domínios auxiliares
identificar relações entre os domínios
24. MAPA DE CONTEXTO
mapa que detalha a relação entre os domínios
possibilita uma visão geral do sistema
separar os pontos de complexidade
identificar pontos auxiliares para o sistema
conseguir atacar o que realmente importa
25.
26. RESUMINDO: PILARES DO DDD
linguagem ubíqua
contextos delimitados (bounded contexts) - até
onde vai a reponsabilidade de cada parte do
sistema
mapas de contexto - comunicação entre os
contextos
28. tudo baseado na linguagem criada antes de chegar
no código
só começa o código quando a complexidade for
definida e entendida
29. A maior parte do esforço está na parte de entender a
complexidade
30. ENTIDADE
algo único no sistema, com representatividade no
negócio
existe no sistema, pode mudar seu estado
este item geralmente possui um id (que não existe
por existir, mas para diferenciar um do outro)
é um domínio rico, tem uma razão de existir
31. Cada contexto tem suas próprias entidades
Posso ter a entidade "Cliente" em mais de um
contexto
uma entidade pode aparecer em diversos contextos
com nomes diferentes
33. OBJETO DE VALOR
classe que não tem identidade única, é usada como
auxiliar
(parar de usar tipos primitivos para tudo)
CPF -> possui validação própria
E-Mail -> possui validação própria
37. REPOSITÓRIO
Parte responsável por persistir as entidades
Geralmente existe apenas para o aggregate root
Ex: eu persisto o pedido, não o item
38. SERVICE
Operação que não é uma parte natural de uma
Entidade ou Objeto de Valor
Geralmente relacionada a um conceito de domínio
É uma operação definida em termos de outros
elementos do modelo
Geralmente é uma operação stateless
39. CONCLUSÃO
DDD é bastante amplo
Foco no negócio
Não se prende a uma tecnologia específica (não é
framework da moda)
Não é só trabalhar com services e
repositories
40. PARA SABER MAIS
Domain Driven Design - Eric Evans
Domain Driven Design Distilled - Vernon Vaughn