arquiteturas perfeitas e o porquÊ seu projeto nasceu falido

ARQUITETURAS PERFEITAS E O PORQUÊ

SEU PROJETO NASCEU FALIDO

YAN DE LIMA JUSTINOMSP | MCP | MCTS | ASP.NET CASTER

ILUSÃO DE ÓTICA?UM MODELO DE SOFTWARE ABRANGENTE PARA DE DOMÍNIO DE NEGÓCIO

DOMAIN-DRIVEN DESIGNYAN DE LIMA JUSTINO

MSP | MCP | MCTS | ASP.NET CASTER

QUEM SOU EUARQUITETO DE SOFTWAREBACHAREL EM ANAL. DE SISTEMASMESTRANDO EM ENG. DE SOFTWARE PELA UFRNMSP | MCP | MCTS

ACADEMIA .NET PARA ZUMBISASP.NET CASTPALESTRANDO EM EVENTOS NACIONAIS

[twitter, facebook]/yanjustinoyanlimaj@[gmail.com, outllok.com]

FORMAÇÃO

ONDE ME ENCONTRAR

MÓDULO 01IMERSÃO AO DDD


AGENDA

• INTRODUÇÃO AO DOMAIN-DRIVEN DESIGN

• MODELAGEM ESTRATÉGICA

• MODELAGEM TÁTICA

OBJETIVOS

Apresentar Tópicos introdutórios referentes ao Domain-Driven Design, as estratégias adotadas na sua modelagem estratégica e tática.

01INTRODUÇÃO AO DDD


O QUE É DOMÍNIO?

• A Domain, in the broad sense, is what an organization does and the world it does it in. (VaughnVernon).

• É uma abstração rigorosamente organizada e seletiva daquele conhecimento (Eric Evans, 2003) – SERA?

• Domínios são nichos de sentidos nos quais experiências ficam estocadas. (Duque e Costa, 2012)

O QUE É DESIGN?

All architecture is design but not all design is architecture. Excerpt From: Simon Brown. “Software Architecture for Developers.”

DOMAIN-DRIVEN DESIGN

Uma ESTRATÉGIA APLICÁVEL ao desenvolvimento de software guiada pela construção de modelos cuja principal finalidade é atacar o volume e a complexidade de informações.

A modelagem de domínio não é umaquestão de se criar um modelo o mais realistapossível. Mesmo em um domínio de coisastangíveis da vida real, nosso modelo é umacriação artificial.

O QUE NÃO É DOMAIN-DRIVEN DESIGN

• NÃO É UM PADRÃO DE LINGUAGEM

• NÃO É UM FRAMEWORK

• NÃO É APENAS SOBRE CÓDIGO

• NÃO É UMA METODOLOGIA

Se assemelha ao processo de criação de um filme, representando livremente a realidadecom uma determinada finalidade.

VALORES DO DOMAIN-DRIVEN DESIGN

FOCO NA COLABORAÇÃO

Sem colaboração e compromisso com os especialistas de negócio, o conhecimento não será capaz de tomar lugar e desenvolviment de equipes não obterão maisprofundos insights sobre o domínio do problemaTrecho de: Scott Millett. IBooks "Princípios, padrões e práticas de Domain-Driven Design.".

FOCO NA LINGUAGEM

Para criar um design flexivel e rico em conhecimento é necessário ter uma linguagemversátil compartilhada

FOCO NA ORGANIZAÇÃO

Habilita a destilação dos domínios de grandes problemas para melhor gerir a comunicação e isolar os modelos que têm ambigüidadedentro de uma linguagem compartilhada

Trecho de: Scott Millett. IBooks "Princípios, padrões e práticas de Domain-Driven Design.”

DDD é sobre a Redução de complexidadeNo softwareEric Evans

Arquitetura é sobreintençãoRobert C. Martin

02DESAFIOS DE ESCREVER

SOFTWARES COMPLEXOSYAN DE LIMA JUSTINO

MSP | MCP | MCTS | ASP.NET CASTER

QUAIS OS DESAFIOS DE CONSTRUIR UM SOFTWARE PARA DOMÍNIOS COMPLEXO?

A FALTA DE ORGANIZAÇÃO

BOLA DE LAMA PATTERN

CÓDIGO SEM LINGUAGEM COMUM

A lack of focus on a shared language and knowledge of theproblem domain results in a code base that works but does notreveal the intent of the business

Excerpt From: Scott Millett. “Principles, Patterns andPractices of Domain-Driven Design.” iBooks.

FALTA DE FOCO NO NEGÓCIO

A lack of focus on a shared language and knowledge of theproblem domain results in a code base that works but does notreveal the intent of the business

Excerpt From: Scott Millett. “Principles, Patterns andPractices of Domain-Driven Design.” iBooks.

03COMO DOMAIN-DRIVE DESIGN PODE AJUDAR


COMO DDD GERENCIA COMPLEXIDADES?

üDESTILANDO O PROBLEMA DE DOMÍNIO PARA REVELAR O QUE REALMENTE IMPORTA

üCRIANDO MODELO PARA RESOLVER PROBLEMAS DE DOMÍNIO

üUSANDO UMA LINGUAGEM COMPARTILHADA PARA HABILITAR MODELAGEM COLABORATIVA

üISOLANDO MODELOS DE AMBIGUIDADE E CORRUPÇÃO

üENTENDENDO A RELAÇÃO ENTRE CONTEXTOS

"Modelos menores proporcionam muitos benefícios, permitindo definir limites clarosrelativos às responsabilidades de concepção e desenvolvimento de equipes.

[Quando] um contexto tem uma superfície menor, você tem menos efeitos colaterais"

JulieLerman isaMicrosoftMVP,.NETmentorandconsultantwholivesinthehillsofVermont.Youcanfindherpresentingondataaccessandother.NETtopicsatusergroupsandconferencesaroundtheworld.Sheblogsat thedatafarm.com/blog andistheauthorof“ProgrammingEntityFramework”(2010), aswellasaCodeFirstedition(2011)andaDbContextedition(2012),allfromO’ReillyMedia.FollowheronTwitterattwitter.com/julielerman andseeherPluralsight coursesat juliel.me/PS-Videos.

04STRATEGIC PATTERNS OF DOMAIN-DRIVEN DESIGN


“Figure 1-3: Applying The Strategic Patterns Of Domain-Driven Design”ExcerptFrom: Scott Millett. “Principles, Patterns and Practices of Domain-DrivenDesign.” iBooks.

SUPERFÍCIE DO PROBLEMA

DECOMPONDO O DOMÍNIO

“The distillation of knowledge after sessions with domain experts should reveal what’s unique and important about the application youare about to create. You can separate the subdomains into core, generic, and supporting domains, as shown ”Excerpt From: Scott Millett. “Principles, Patterns and Practices of Domain-DrivenDesign.” iBooks.

SUPERFÍCIE DA SOLUÇÃO

DOMÍNIO vs MODELAGEM DE DOMÍNIO

DESAFIOS DA MODELAGEM DE DOMÍNIO

SINERGIA MODELAGEM DE DOMÍNIO

BOUNDED CONTEXT

DIFERENÇA ENTRE MODELO DE NEGÓCIO E MODELO DE DOMÍNIO

MANIFESTAÇÃO DO BOLO DE LAMA

05PADRÕRES DE

REPRESENTAÇÃO DO DOMÍNIO


VAMOS FAZER UM TESTE

CAMADA DE DOMÍNIO

“The Domain LayerThe domain layer, at theheart of your application, is the area of code thatcontains your domain model.”Excerpt From: Scott Millett. “Principles, Patterns and Practices ofDomain-Driven Design.” iBooks.

COLOCANDO MODELOS EM CONTEXTO

CONTEXTOS EM CÓDIGO LEGADO

COMUNICAÇÃO ENTRE CONTEXTOS

06ARQUITETURA


ARQUITETURA HEXAGONAL

REFERÊNCIAS

• http://www.infoq.com/presentations/ddd-imperfect-design

• https://skillsmatter.com/skillscasts/6259-ddd-and-microservices-at-last-some-bounderies

• Domain-Driven Design (Eric Evans)

• Patterns, Principles and Practices of Domain-Driven Design (Millett and Tune)

• Implementing Domain-Driven Design(Vaughn Vernon)