DDD - Part 6 - An Extended Example

07 April 2009

Os últimos assuntos mostraram os patterns e a linguagem utilizados para modelar e manter um software seguindo MODEL-DRIVEN-DESIGN. Para exemplificar, um sistema de entregas é modelado, seguindo 3 funções básicas:
  • 1. Track key handling of customer cargo
  • 2. Book cargo in advance
  • 3. Send invoices to customers automatically when the cargo reaches some point in its handling
As principais necessidades captadas do domínio são:
"Multiple Customers are involved with a Cargo, each playing a different role"
"The Cargo delivery goal is specified"
"A serie of Carrier Movements satisfying the Specifications will fulfill the delivery goal"
Isolando o domínio Como visto antes, DDD aplica LAYERED ARCHITECTURE, e para o sistema em questão, divide em 3 classes:
  • 1. A Tracking Query that can access past and present handling of particular Cargo
  • 2. A Booking Application that allows a new Cargo to be registered and prepares the system for it
  • 3. An Incident Logging Application that can record each handling of the Cargo
A partir disso, pode-se iniciar a distinção entre Entitys e Value Objects Entity => Customer, Cargo, Handling Event, Carrier Movement, Location, Delivery History Value Object => Delivery Specification, Roles Uma profunda análises dos relacionamentos começa a partir de então, eliminando referencias circulares do modelo, substituindo query's por listas, encontrando Aggregates, etc. Além disso, são definidos os repositórios Customer repository, Location Repository e Carrier Movement Repository. 3 Factories são sugeridas, todas visando o mesmo resultado:
"A Cargo with an empty Delivery History, and a null Delivery Specification."
Uma pausa pra Refactoring acontece também:
"Modeling and design is not a constant forward process."
"Replacing the Delivery History's collection of Handling Events with a query would allow Handling Events to be added without raising any integrity issues outside its own AGGREGATE."
Nesse momento, o diagrama de classes corresponde a: cimg00011 O capítulo fecha com a adição de uma nova feature, mostrando como fazer as relações com partes não esperadas e até mesmo não escritas da aplicação, linkando o modelo construído com a nova necessidade. Aqui acaba a parte II do livro (de um total de IV). Próximo: Refactoring Toward Deeper Insight
comments powered by Disqus