DDD - Part 2 - Model Driven Design e isolamento do domínio

07 March 2009

Programadores devem participar da analise do sistema ? "Analistas" devem escrever código ? É dessa forma que contínua o assunto sobre DDD, defendendo a teoria de que não deve existir a separação analista - programador. Programadores são analistas. Programadores devem modelar o comportamento do sistema.
"Projects that have no domain model at all, but just write code to fulfill one function after another, gain few of the advantages of knowledge crunching and communication discussed before. A complex domain will swamp them."
"Some knowledge crunching happens durin such an anallysis, but most of it is lost when coding begins, when the developers are forced to come up with new abstractions for the design. Then there is no guarantee that the insights gained by the analysts and embedded in the model will be retained or rediscovered. At this point, maintaining any mapping between the design and the loosely connected model is not cost-effective."
"crucial discoveries always emerge during the design/implementation effort"
"You can't just take any model and turn it into a workable design. The model has to be carefully crafted to make for a practical implementation. Design and implementation techniques have to be employed that allow code to express a model effectively."
"When a design is based on a model that reflects the basic concerns of the user to a greater extent than with other design aproaches. Revealing the model gives the user more acces to the potential of the software and yields consistent, predictable behavior."
"changes to the code changes the model. Programmers are modelers."
Depois dessa discussão, DDD apresenta alguns padrões de projetos para construir o software baseado no isolamento do domínio e na Ubiquitous Language, os padrões são:
    MDD Patterns
  • Layered Arquiteture
  • Services
  • Entities
  • Value Objects
  • Repositories
  • Aggregates
  • Factories
    MDD Anti-pattern
  • Smart UI
Domain Driven Design assume e parte do princípio que é necessário dividir o sitema em camadas(Layered Arquiteture), seguindo pelo menos o padrão baixo: User Interface - Application Layer - Domain Layer - Infrastructure Layer
"The infrastructure layer usually does not initiate actions in the domain layer. It should have no specific knowledge of the dommain it is serving. Indeed, such technical capabilities are most often offered as SERVICES""
Ants de continuar com padrões, DDD fala sobre Smart UI, onde toda regra de negócios fica na camada de visualização, ou seja, todos os select do banco, todas as regras de negócio, etc estão na view. Por incrível que pareça essa arquitetura é defendida pelo autor para projetos muito pequenos e rápidos, porém impossível de utiliza-la em projetos grandes e que sigam DDD. Smart UI
  • Productivity is high and immediate for simple applications.
  • Less capable developers can work this way with little training
  • Integration of the application is difficult except through the database.
  • There is no reuse of the behavior and no abstractionof the business problem. Business rules have to be duplicated in each operation to which they apply.
  • Rapid prototyping and interation reach a natural limit because the lack of abstraction limitis refactoring options.
  • Complexity buries you quickly, so the growth path is strictly toward additional simple applications. There is no graceful path to richer behavior
Um dos pontos fracos e principail deficiencia da Smart UI é o fato de não conseguir migrar pra outro design sem refazer a aplicação inteira.
comments powered by Disqus