DDD – Part 6 – Using the Language: An Extended Example

Posted on April 7, 2009

0


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

Posted in: ddd, oo