Arquitetura e modelagem de Software orientada a domínio
Domain Driven Design
Lorival Smolski ChapuisMCPD ASP.NET
http://blog.lorival.com / [email protected]
Centro de Inovação MicrosoftSOCIESC 2010
Sociedade Educacional de Santa Catarina
“... 1 hora não dá pra nada. Você vai mostrar amecânica do DDD, e o pessoal vai sair achando queDDD é entidades+repositórios... Já percebi que pormais esforço que façamos, técnicos tendem asimplificar o que viram, e sobra só isso na cabeçadeles ...”
Giovani BassiArquiteto de Software, MVP
Considerações iniciais
2
• O que é Domain Driven Design• Surgimento, objetivos e vantagens• Essência do Domain Driven Design• Modelando um domínio real• Regras para modelagem• Arquitetura em camadas• Caixa de ferramentas Microsoft• Apresentação de uma aplicação• Considerações finais
Agenda
3
É uma abordagem de design de softwaredisciplinada que reúne um conjunto deconceitos, técnicas e princípios paraconstrução de softwares baseados em ummodelo de domínio.
Domain Driven Design
4
É uma abordagem de design de softwareDisciplinada que reúne um conjunto deconceitos, técnicas e princípios paraconstrução de softwares baseados em ummodelo de domínio.
Domain Driven Design
5
É uma abordagem de design de softwareDisciplinada que reúne um conjunto deconceitos, técnicas e princípios paraconstrução de softwares baseados em ummodelo de domínio.
Domain Driven Design
6
É todo e qualquer conhecimento (esfera de conhecimento) utilizado em uma
determinada área.Um domínio possuí regras de negócio.
É uma abordagem de design de softwareDisciplinada que reúne um conjunto deconceitos, técnicas e princípios paraconstrução de softwares baseados em ummodelo de domínio.
Domain Driven Design
7
É uma abordagem de design de softwareDisciplinada que reúne um conjunto deconceitos, técnicas e princípios paraconstrução de softwares baseados em ummodelo de domínio.
Domain Driven Design
8
Pode ser expresso de várias formas: apresentação de slides, UML, rascunhos
em papel, organograma, etc...
É uma abordagem de design de softwareDisciplinada que reúne um conjunto deconceitos, técnicas e princípios paraconstrução de softwares baseados em ummodelo de domínio.
Domain Driven Design
9
É uma abordagem de design de softwareDisciplinada que reúne um conjunto deconceitos, técnicas e princípios paraconstrução de softwares baseados em ummodelo de domínio.
Domain Driven Design
10
Object Orientedprogramming
UbiquitousLanguage
Domainpatterns
Layeredarchitecture
Design patterns
...
...
Surgimento
11
Há 20 anos criam-se padrões
e técnicas para arquitetura emodelagem de softwareOrientada a Objetos.
Há 6 anos Eric Evanscompilou várias destastécnicas e unindo com suasexperiências criou o DDD
Há 20 anos criam-se padrões
e técnicas para arquitetura emodelagem de softwareOrientada a Objetos.
Há 6 anos Eric Evanscompilou várias destastécnicas e unindo com suasexperiências criou o DDD
Surgimento
12
Design de domínio
Pouco foi escrito sobre isso
Não se tinha claro como
deveria ser feito
Há 20 anos criam-se padrões
e técnicas para arquitetura emodelagem de softwareOrientada a Objetos.
Há 6 anos Eric Evanscompilou várias destastécnicas e unindo com suasexperiências criou o DDD
Surgimento
13
Padrões de arquitetura
Mais de 10 anos como arquiteto
de software
Boas práticas
Padrões de desenvolvimento
Grandes e pequenos projetos
1. Aproximar desenvolvimentode software do domínio doproblema.
2. Aumentar a vida de umsoftware.
3. Ter códigos mais claros efáceis de entender.
4. Utilizar o principal recurso daorientação a objetos: aaproximação do mundo realatravés de abstrações.
Objetivos
14
Vantagens
15
1. Fácil comunicação entredesenvolvedores, analistas eclientes.
2. Construir software testáveis.
3. Fácil manutenção ecrescimento do software.
4. Agregar ou trocarcolaboradores na equipe dedesenvolvimento não é maisum problema.
5. Entenda o cliente, o modelo eo código.
• Para a maioria dos projetos de software o focoprincipal deve ser no domínio
• O modelo deve ser baseado em um domínio
• Você conhece software, o BusinessExpert conheceo domínio, ouve-o.
• A Ubiquitous Language deve predominar desde oBusinessExpert até a equipe de desenvolvimento
Essência do Domain Driven Design
16
Modelos são baseados em abstrações
17
Modelos são baseados em abstrações
18
Modelos são baseados em abstrações
19
Modelos são baseados em abstrações
20
Modelos são baseados em abstrações
21
Modelos são baseados em abstrações
22
Modelos são baseados em abstrações
23
Modelos são baseados em abstrações
24
• Objetivo principal: Extrair empresas de sites
Vamos modelar...
25
Empresa: Emp ARua A, 001. cep: AA
Cidade: Cidade A, AA
Empresa: Emp BRua B, 002. cep: BB
Cidade: Cidade B, BB
Empresa: Emp CRua C, 003 . cep: CC
Cidade: Cidade C, CC
Empresa Rua Nº CEP Cidade Estado
Emp A A 001 AA Cidade A AA
Emp B B 002 BB Cidade B BB
Emp C C 003 CC Cidade C CC
Atividades atuais
26
Regras de modelagem
27
• São identificadas através de uma identidade• Um objeto pode ter uma identidade em um domínio
e não ter em outro
versus
• Se uma entidade mudar a regra de negócio é afetada
Entidades
28
• São identificadas através de suas propriedades (atributos)
• Um objeto de valor não pode ser alterado, ele é sempre removido e adicionado um novo
• Não são o foco do negócio
Objetos de valor
29
Atividades atuais
30
Entidades
31
Atividades atuais
32
Entidades
33
Atividades atuais
34
Entidades
35
Atividades atuais
36
Objetos de valor
37
Objetos de valor
38
• Reúnem entidades e objetos de valor de modo a fazer sentido para o negócio.
• Definem fronteiras claras
• Toda agregação tem uma raiz
Agregações
39
Agregações
40
Agregações
41
Agregações e suas raizes
42
Agregações e suas raízes
43
• Fingem que tem todos os dados em memória.
• Para o consumidor do repositório não faz diferença onde está o objeto.
• São responsáveis por guardar ou destruir objetos.
Repositórios
44
Repositórios
45
Modelo incompleto
46
• Resolvem problemas de negócio mas não sãoentidades nem objetos de valor, pois possuemapenas comportamentos e não estados de negócio.
Serviços
47
Serviços
48
• Cria objetos complexos ou que possuam dificuldade de construir.
• Será responsabilidade de um objeto se construir?
Fábricas
49
Fábricas
50
Modelo completo
51
Arquitetura
52
• Mínimo:– Microsoft Visual Studio 2010 (IDE)– Microsoft.Net Framework
• Comum:– Microsoft Entity Framework 4.0 (ORM)– Microsoft Unity Framework (Inje. Dependência)– Microsoft Sql-Server 2008
• Recomendado:– Microsoft Test (Testes automatizados)– Code Coverage– Microsoft MVC Framework (web)
Caixa de ferramentas
53
Aplicação
54
Considerações finais
55
Considerações finais
56
Domain Driven Design
Dúvidas?
Centro de Inovação MicrosoftSOCIESC 2010
Sociedade Educacional de Santa Catarina
Lorival Smolski ChapuisMCPD ASP.NET
http://blog.lorival.com / [email protected]