Domain driven design - Visão Geral

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.


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.


5



6

É todo e qualquer conhecimento (esfera de conhecimento) utilizado em uma

determinada área.Um domínio possuí regras de negócio.



7



8

Pode ser expresso de várias formas: apresentação de slides, UML, rascunhos

em papel, organograma, etc...



9



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




Surgimento

12

Design de domínio

Pouco foi escrito sobre isso

Não se tinha claro como

deveria ser feito




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


18


19


20


21


22


23


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


Dúvidas?

Centro de Inovação MicrosoftSOCIESC 2010

Sociedade Educacional de Santa Catarina

Lorival Smolski ChapuisMCPD ASP.NET

http://blog.lorival.com / [email protected]

Education

Domain driven design - Visão Geral