domain-driven design - uma abordagem introdutória

Domain-Driven Domain-Driven DesignDesign

Uma Abordagem IntrodutóriaUma Abordagem Introdutória

ApresentaçõesApresentações

Armênio CardosoArmênio CardosoConsultor, Arquiteto de Sistemas e Consultor, Arquiteto de Sistemas e

ProfessorProfessor

http://www.http://www.linkedinlinkedin.com/in/.com/in/armeniocardosoarmeniocardoso

http://www.http://www.slideshareslideshare.net/.net/armeniocardosoarmeniocardoso

ReflexõesReflexões• Quanto mais Quanto mais simplessimples algo é, mais algo é, mais fácilfácil é é

o seu o seu entendimentoentendimento..

• Quanto mais Quanto mais complexocomplexo algo é, mais algo é, mais difícildifícil é o seu é o seu entendimentoentendimento..

• Quanto Quanto menosmenos você você entendeentende algo, mais algo, mais difícildifícil é consertá-lo ou modificá-lo. é consertá-lo ou modificá-lo.

ConclusãoConclusão: quanto mais complexo um : quanto mais complexo um sistema fica, mais difícil e caro é mantê-sistema fica, mais difícil e caro é mantê-

lo.lo.Max Kanat-Alexander, Code Simplicity.

ReflexõesReflexões

• O O DesejoDesejo de construir um software é de construir um software é diretamente proporcional ao seu diretamente proporcional ao seu ValorValor e inversamente proporcional ao e inversamente proporcional ao EsforçoEsforço dedicado a desenvolvê-lo. dedicado a desenvolvê-lo.

D = (Vn + Vf) / (Ei + Em)D = (Vn + Vf) / (Ei + Em)

Max Kanat-Alexander, Code Simplicity.

Vi = Valor de ImplementaçãoVf = Valor FuturoEi = Esforço de ImplementaçãoEm = Esforço de Manutenção

ReflexõesReflexões

Nossa MissãoNossa Missão

Desenvolver sistemas que...Desenvolver sistemas que......tenham o ...tenham o máximomáximo de de ValorValor......

...com o ...com o mínimomínimo de de EsforçoEsforço de de desenvolvimento.desenvolvimento.

ReflexõesReflexões• Cada vez mais as pessoas parecem Cada vez mais as pessoas parecem

confundir complexidade com sofisticação.confundir complexidade com sofisticação.

• O incompreensível deveria causar O incompreensível deveria causar suspeita e não admiração. suspeita e não admiração.

• Possivelmente, esta tendência resulta de Possivelmente, esta tendência resulta de uma crença errônea de que o uso de uma crença errônea de que o uso de mistério confere uma aura de poder.mistério confere uma aura de poder.

Niklaus Wirth, “pai” da Linguagem Pascal.

DefiniçõesDefinições

• Domain-Driven DesignDomain-Driven Design é uma é uma abordagem para o Desenvolvimento abordagem para o Desenvolvimento de Software que estabelece uma forte de Software que estabelece uma forte ligação entre a implementação e o ligação entre a implementação e o modelo evolutivo dos conceitos de modelo evolutivo dos conceitos de negócio.negócio.

Implementação X NegóciosImplementação X Negócios


• Domain-Driven DesignDomain-Driven Design não é uma não é uma tecnologia ou uma metodologia. tecnologia ou uma metodologia.

• DDDDDD fornece uma estrutura de práticas fornece uma estrutura de práticas e terminologia para a tomada de e terminologia para a tomada de decisões de design.decisões de design.

• O foco é acelerar os projetos de O foco é acelerar os projetos de

software e alinhar com os domínios de software e alinhar com os domínios de negócio.negócio.

DefiniçõesDefinições• DomínioDomínio

– A esfera do conhecimento, influência ou A esfera do conhecimento, influência ou atividade de negócio.atividade de negócio.

– A área de negócio que será abordada pelo A área de negócio que será abordada pelo projeto de software.projeto de software.

• ModeloModelo– Um sistema de abstrações que descreve Um sistema de abstrações que descreve

aspectos selecionados de um domínio com aspectos selecionados de um domínio com o objetivo de resolver problemas de o objetivo de resolver problemas de negócio.negócio.


• Idioma onipresente Idioma onipresente (ubiquitous)(ubiquitous)– Uma linguagem estruturada em torno do Uma linguagem estruturada em torno do

modelo de domínio e usado por todos os modelo de domínio e usado por todos os membros da equipe para conectar todas membros da equipe para conectar todas as atividades da equipe com o software.as atividades da equipe com o software.

• ContextoContexto – A situação onde uma palavra ou A situação onde uma palavra ou

declaração aparece, determinando o seu declaração aparece, determinando o seu significado.significado.

Peças do DDDPeças do DDD

Model-Driven Design

Layered Architect

ure

Arquitetura em CamadasArquitetura em Camadas

Arquitetura em CamadasArquitetura em Camadas• User InterfaceUser Interface: responsável pela apresentação : responsável pela apresentação

das informações e interpretação das interações das informações e interpretação das interações dos usuários.dos usuários.

• Application LayerApplication Layer: coordena as atividades da : coordena as atividades da aplicação.aplicação.

• Domain LayerDomain Layer: contém os componentes de : contém os componentes de negócio – é o centro da aplicação.negócio – é o centro da aplicação.

• Infraestructure LayerInfraestructure Layer: provê o suporte para : provê o suporte para as outras camadas, bibliotecas, persistência etc.as outras camadas, bibliotecas, persistência etc.


Entities

Peças do DDDPeças do DDD• EntitiesEntities

– Entidades derivam objetos com identidade, Entidades derivam objetos com identidade, distinção e continuidade (ciclo de vida).distinção e continuidade (ciclo de vida).

– Entidades podem ter atributos alterados sem Entidades podem ter atributos alterados sem que a identidade do objeto seja afetada.que a identidade do objeto seja afetada.

– Entidades contém Entidades contém métodos de negóciométodos de negócio que que implementam regras que se aplicam ao implementam regras que se aplicam ao objeto em questão.objeto em questão.

• Pessoa, Aluno, Professor, Nota-fiscal.Pessoa, Aluno, Professor, Nota-fiscal.


Value Objects

Peças do DDDPeças do DDD• Value ObjectsValue Objects

– Value Object é um tipo de objeto que é Value Object é um tipo de objeto que é imutável e não tem identidade.imutável e não tem identidade.

– Value Object deriva objetos que são definidos Value Object deriva objetos que são definidos pelos seus atributos e por isso são imutáveis.pelos seus atributos e por isso são imutáveis.

– Objetos de valor não têm métodos de Objetos de valor não têm métodos de negócio.negócio.

• Endereço, Itens da Nota-Fiscal, Unidade da Endereço, Itens da Nota-Fiscal, Unidade da Federação, Estado Civil, Usuário (login e senha).Federação, Estado Civil, Usuário (login e senha).


Aggregates

Peças do DDDPeças do DDD• AggregatesAggregates

– É uma Entidade composta por outros objetos (Entities É uma Entidade composta por outros objetos (Entities e/ou Value Object) vista como uma unidade.e/ou Value Object) vista como uma unidade.

– Essa Entidade é denominada de Raiz da Agregação.Essa Entidade é denominada de Raiz da Agregação.

– A raiz de agregação garante a consistência das A raiz de agregação garante a consistência das mudanças que são feitas dentro do agregado, mudanças que são feitas dentro do agregado, impedindo que objetos externos realizem referências a impedindo que objetos externos realizem referências a seus membros.seus membros.

• Nota-Fiscal é um agregado que contém Itens de Nota-Fiscal.Nota-Fiscal é um agregado que contém Itens de Nota-Fiscal.• Cliente é um agregado que contém Endereços.Cliente é um agregado que contém Endereços.


Services

Peças do DDDPeças do DDD• ServicesServices

– Quando uma operação de negócio não Quando uma operação de negócio não pertence conceitualmente a um único pertence conceitualmente a um único objeto esta reside em um Service.objeto esta reside em um Service.

– Services têm uma ligação estreita com os Services têm uma ligação estreita com os casos de uso modelados no sistema.casos de uso modelados no sistema.

– Services não têm estado.Services não têm estado.• A classe SecretariaService contém um método A classe SecretariaService contém um método

matricularAluno que recebe Aluno e Turma matricularAluno que recebe Aluno e Turma como parâmetros.como parâmetros.

Peças do DDDPeças do DDD• ServicesServices

– A A Camada de ServiçoCamada de Serviço define os limites de uma define os limites de uma aplicação e seu conjunto aplicação e seu conjunto de operações disponíveis de operações disponíveis a partir da perspectiva do a partir da perspectiva do cliente. cliente.

– Ela encapsula a lógica de Ela encapsula a lógica de negócios, transações e negócios, transações e coordenação das coordenação das respostas na respostas na implementação de suas implementação de suas operações.operações.

http://martinfowler.com/eaaCatalog/serviceLayer.html


Factories


• FactoriesFactories– Métodos para criar objetos de domínio Métodos para criar objetos de domínio

complexos devem delegar a objetos de complexos devem delegar a objetos de fábrica especializados, de forma que as fábrica especializados, de forma que as implementações possam ser facilmente implementações possam ser facilmente mantidas.mantidas.

– São úteis na criação de Aggregates.São úteis na criação de Aggregates.


Repositories


• RepositoriesRepositories– Um repositório é um mecanismo para Um repositório é um mecanismo para

encapsular o armazenamento, encapsular o armazenamento, recuperação e comportamento de busca, recuperação e comportamento de busca, que emula uma coleção de objetos.que emula uma coleção de objetos.

– Para cada tipo de objeto que precisa de Para cada tipo de objeto que precisa de acesso global, criar um Repositório que acesso global, criar um Repositório que pode fornecer a ilusão de uma coleção em pode fornecer a ilusão de uma coleção em memória de todos os objetos desse tipo.memória de todos os objetos desse tipo.

Critérios de SucessoCritérios de Sucesso• Use Use DDDDDD se se

– O seu domínio não é trivial.O seu domínio não é trivial.

– A equipe de desenvolvimento tem A equipe de desenvolvimento tem experiência e interesse em OOP/OOD.experiência e interesse em OOP/OOD.

– Existe o acesso aos detentores das Existe o acesso aos detentores das informações sobre o domínio.informações sobre o domínio.

– O processo de desenvolvimento é iterativo.O processo de desenvolvimento é iterativo.

Critérios de SucessoCritérios de Sucesso

• Domain-Driven Design Domain-Driven Design é um tema é um tema muito amplo e contém muitas coisas que muito amplo e contém muitas coisas que são difíceis ou impossíveis de incorporar são difíceis ou impossíveis de incorporar no código de um aplicativo simples.no código de um aplicativo simples.

• Coisas a se destacarCoisas a se destacar– Comunicação com o especialista de domínio.Comunicação com o especialista de domínio.– Modelagem iterativa.Modelagem iterativa.– Descoberta de uma linguagem onipresente.Descoberta de uma linguagem onipresente.

Perguntas?Perguntas?ee

Obrigado!Obrigado!

domain-driven design - uma abordagem introdutória

Documents