Ciclo de vida - DDD

Todos os objetos têm um ciclo de vida, alguns têm vida longa, passando por vários estados e sendo persistidos para posterior utilização, outros têm a vida mais curta sendo apenas utilizados em memória, alguns são criados apenas com uma simples chamada em seu construtor, outros exigem mais processamento para serem criados. Controlar estes objetos implica em 2 desafios para um Design Dirigido por Modelos, manter a integridade do objeto durante todo o ciclo de vida e impedir que o modelo se deixe levar pela complexidade do gerenciamento do ciclo de vida. Para tratar destas questões utilizaremos os padrões Agradado, Fábrica e Repositório.

Modelo expresso em Software - DDD

Para um modelo de domínio refletir a abstração do domínio de um software da forma mais adequada possível, as classes são categorizadas de acordo com o papel que cada uma desempenha. Cada papel tem certas responsabilidades e relacionamentos com outras classes que desempenham outros papeis. Sendo assim, definir o papel de cada classe facilita a implementação do modelo de domínio. As classes que implementam o modelo de domínio podem ser categorizadas em: 

Arquitetura em Camadas - DDD

Existem várias maneiras de dividir um sistema de software, mas por questões de convenções e experiência a arquitetura em camadas é a mais adotada. A arquitetura de camadas nos ajuda a ter alta coesão, baixo acoplamento e separar as responsabilidades.

Alguns arquitetos de software se preocupam muito mais com a infraestrutura (frameworks e tecnologias) da arquitetura do que com o problema que o software se propõem a resolver. Uma arquitetura de ponta pode trazer boa resposta no desenvolvimento do sistema, mas se toda essa tecnologia não conseguir resolver o problema proposto, a arquitetura não conseguiu agregar valor ao cliente.

Modelagem de Domínio - DDD

Atualmente é aceito que na maioria dos projetos de software a real complexidade do desenvolvimento está em entender o domínio no qual o software é aplicado. Para ajudar com essa questão, a modelagem de domínio é amplamente incentivada pelo Domain-Drive Design.

Linguagem Onipresente - DDD

Em um projeto existem vários envolvidos, os especialistas do domínio, desenvolvedores, clientes, patrocinadores e outros interessados no projeto.
Dentre estes envolvidos, os especialistas do negócio têm um grande entendimento do domínio do sistema, mas são limitados quanto aos termos técnicos utilizados para o desenvolvimento de software. 

Com os desenvolvedores está situação também ocorre, mas de maneira inversa, tem conhecimento de como o sistema deve ser feito, mas não tem o conhecimento necessário para fazê-lo, falta-lhes conhecimento de como o sistema deve se comportar, como deve agir em cada situação, essas informações serão passadas pelos especialistas do domínio.

Domain-Driven Design - DDD

Eric Evans, compilou uma série de técnicas e conceitos de desenvolvimento de software, está nova abordagem visa um maior entendimento do negócio.

Um software está sempre relacionado com a necessidade, negócio ou atividade diária de seus usuários. Essa área de interesse onde o usuário aplica o programa é denominada domínio. Se o software é utilizado para em um sistema de controle aéreo seu domínio é o controle de aviões, se é utilizado para fazer matrículas de alunos de uma escola, seu domínio é o cadastro de alunos, o domino é a área na qual o software é aplicado.