Layered Model variant of DDDSample.Net
Layered Model is built to demonstrate one of Domain-Driven Design strategic design patterns -- layers in the model. The concept of layers in the model is, in contrary to architecture layers, not a technical solution. Layers in the model should be business oriented
and be understood by domain expert. What layers should be included is dependant on the problem at hand, but there are some classic solutions, applicable in many cases.
There are four layers in DDDSample.Net:
This layer is responsible for making high-level strategic decisions such as Routing. It uses underlying policy layer to guide the decision-making process.
This layer is responsible for implementing company policies guiding decision-making process. In DDDSample.Net domain case, it contains two main concepts: CustomerAgreement and IRoutingPolicy. The former represents the commitment of delivering cargoes for certain
customer. The latter represents the best route selection policy. Currently, there are three possible policies. When customer do have permanent agreement regarding routing, is it represented by CustomerAgrrement object referencing either CheapestRoutingPolicy
or FastestRoutingPolicy. Otherwise, NullRoutingPolicy (Null Object Pattern) is used.
This layer is responsible for modeling the tactical day-to-day business activities. In this case, it means cargoes and handling events. This layer is present in all versions of DDDSample.Net.
This layer contains objects representing entities that are not part of day-to-day business activities, but are the enablers of these activities. These objects represent the company potential.
Customer and Location objects are pretty straightforward. The Voyage aggregate is slightly more complicated. Each Voyage represents real-world vessel voyage from its origin to destination, starting and ending at particular dates. Voyage is assigned a unique
id and a non-unique number. A voyage number represents a route traveled by vessels, not a particular voyage, but since this is a guideline, not a strict rule, vessel routes are not represented as stand-alone concepts. Rather than each voyage contains its schedule
which outline the route consisting of a collection of so-called carrier movements. Each carrier movement represents a voyage between two locations. Carrier movements are aggregates on their own. They need to be identified because a lot of high-level concepts
such as routing policies depend on various properties of movements (such as estimated cost).