DDD@henriquericcio

Antes de mais nada

Revisitando conceitos e princípios.

LayersÉ uma forma de agrupar elementos que possuem uma mesma responsabilidade.Ex.:Camada de DadosCamada de Lógica de NegócioCamada de Integração

ModeloÉ aquilo que abstrai e expressa algo.Ex.:● Modelo matemático;● Planta de edifícios;● Modelo de domínio;

Modelar é importante, pois viabiliza a transmissão de informações sobre o assunto.

Uncle BobRobert C. Martin

Escreveu diversos livros e artigos sobre OOP.E aprensentou os seguintes princípios:● ISP - Interface Segregation Principle● SRP - Single Responsability Principle● DIP - Dependency Inversion Principle

"Clientes não devem ser forçados a depender de interfaces que eles não usam"

ISP

SRP

"Uma classe deve ter apenas uma simples responsabilidade"

DIP

"algo deve depender de abstrações e não de implementações."

Design PatternsDesign Patterns: Elements of Reusable Object-Oriented Software é um livro de engenharia de software que descreve soluções recorrentes para problemas comuns na modelagem de software.

Factory MethodUm pattern criacional, responsável por abstrair o processo de criação de objetos complexos.

P of EAAUm livro sobre design de software orientado a objeto escrito por Martin Fowler e Colaboradores, no qual abordou diversos padrões.

RepositoryMediador entre o domínio e as camadas de mapeamento de objeto, usando uma interface do estilo de coleção, para acessar objetos de domínio.

Service LayerDefine um limite de aplicação com uma camada de serviços que estabelece um grupo de operações disponíveis e coordena a resposta da aplicação para cada operação.

Value Object

Um pequeno e simples objeto, como money ou date range, cuja igualdade não é baseada na identidade, mas sim nos valores de seus atributos.

Data Transfer ObjectUm objeto que transfere dados entre processos com o intuíto de reduzir o número de chamadas ao método.

Separated InterfaceDefine uma interface em um pacote separado de sua implementação.

Remote FacadeProvê uma fachada, de baixa granularidade, para acesso de objetos altamente granulares no intuito de melhorar a eficiência de transmissão de rede.

Domain ModelUm modelo de objetos do domínio que incorpora comportamento e dados.

Agora sim...

Vamos comecar a falar de DDD.

Domain-Driven DesignModelagem orientada ao domínio

Erick Evans lançou em 2003 o “Domain-Driven Design: Tackling Complexity in the Heart of Software”.

Mas o que é?Uma compilação de práticas para criação de softwares que expressem as necessidades de negócio através do modelo de domínio.

Layered Architecture

O Domain Layer deve ser o mais isolado possível.Usar DI ajuda!!!

User Interface LayerResponsável por apresentar informação para o usuário e interpretar seus comandos.

User Interface não é necessariamente uma tela!

Application LayerUma fina camada que coordena a atividade da aplicação. Ela não contem regra de negócio, não mantém estado dos objetos de negócio, mas pode manter o estado de uma tarefa da aplicação.

Domain LayerEsta camada contém informação sobre o domínio. Este é o coração do software.O estado dos objetos é mantido aqui. Persistência dos objetos de negócio e possivelmente seu estado são delegados à camada de infraestrutura.

Infrastructure LayerEsta camada age como uma biblioteca de suporte para todas as outras camadas. Ela provê comunicação entre camadas, implementa persistência para objetos de negócio, contem bibliotecas de suporte para a camada de interface, etc

Domain PatternsO DDD define o uso de alguns padrões para modelagem de domínio:● Repository● Domain Service● Factories● Entities● Value Objects● Aggregates

Entity

● Possui uma identidade;● Implementadas como

POCO's (POJO's);● Métodos fortes (negócio);● Constructor com a

identidade;

Value Object

● Imutáveis;● Reconhecidos pelos seus

atributos;● Constructor define o valor de

todos os atributos do objeto;

Domain ServicesÉ a representação de serviços oferecidos ao domínio. Todo comportamento que não pode ser de responsabilidade de uma entidade, é representado desta forma.

Factories● Para criação de entidades;● Encapsula a complexidade de criação;

RepositoriesRepresenta, no domínio, a persistência da entidade, que pode ser efetivamente realizada em banco de dados, arquivo, ou até integração com outro sistema.

AggregatesObjetos se associam, uns aos outros, criando relações complexas.Dentre os objetos de uma relação, um possuí maior expressão (naquele contexto).

Ex.: Conta Corrente e Lançamento

Ubiquotous LanguageTraduzindo, “Linguagem Onipresente”, é a que está em todo lugar. É a linguagem de quem entende do negócio.É uma forma de todos falarem a mesma língua, a língua do negócio (Domínio).

Bounded Context

Continuous RefactoringRefactoring do modelo!Se a compreensão do problema mudou, refatore!

Quando usar?

Quando o projeto envolve regras complexas como processamento de uma fatura de cartão de crédito.

RecursosLivro Patterns of Enterprise Application Architecture - Martin Fowler

http://martinfowler.com/books/eaa.htmlPrincípios de Design OO - Uncle Bob

http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOodDesign Patterns: Elements of Reusable Object-Oriented Software (material oficial)

http://c2.com/cgi/wiki?DesignPatternsBookDesign patterns e exemplos em C#

http://www.dofactory.com/Patterns/Patterns.aspxE-book gratuíto sobre DDD

http://www.infoq.com/minibooks/domain-driven-design-quicklyO livro do Eric Evans

http://www.amazon.com/exec/obidos/ASIN/0321125215/domainlanguag-20Exemplo em C# usado para esse treinamento

https://github.com/henriquericcio/ExemploDDD