# Step 1 - Evans "Making a booking."

Location: Page 17, "Knowledge-Rich Design.

We start with a very simple domain design, consisting of a Voyage with Cargo items. The booking system is responsible for matching as many Cargo items on to the Voyage but not too many. Evans introduces a capacity property in the Voyage and a size property to the Cargo.

Mr Evans continues to discuss that a makeBooking( Cargo cargo, Voyage voyage ) method (presumably in some service instance somewhere) becomes too complicated for the domain experts and suggests breaking out the policy into a separate class.

Let's start with putting into the code that Mr Evans suggests, using so called POJO or JavaBeans programming convention.

You will find the suggested code in this package. Take a look at it. You can also run the testcase step1 to see simple usage cases.

We have made this code more complex than the book is suggesting. First of all there is a separation of interface from implementation. This is done to make the code more flexible for future change;

- The Voyage.addCargo() must be hidden from the client code, so that it is forced to call the ShippingService.makeBooking() and not bypassing it and call the addCargo() directly.
- DDD book doesn't mention the ShippingService in this section, but was introduced to make the code executable. Making the ShippingService an interface is just following common practices, which allows us to change the, or have multiple, implementations.
- Cargo also has separated interface from the implementation for the same reason.
- Sequence is separated largely because in a real application, it is probably dependent on the customer.
- Finally, the OverbookingPolicy is also separated since we want to be able to have many Policies sooner or later.
- And with this separation, and hiding of the implementation from the client by putting all of the implementation details in the internal package, we also need to add methods to create Cargo and find Voyage instances.

This could have been done utilizing Spring Framework, but we don't want to introduce a fairly large dependency, and it wouldn't help us much in the domain aspect of this example.

Mr Evans then continues to discuss "Deep Models", where he correctly observes that the domain model artifacts tend to change over time as we start to understand the domain better. The conclusion is that the model will change a lot and the easier we make this process the faster we can move forward.

Now, what we have done so far is to just use plain Java to implement the discussion of Mr Evans' Cargo example of domain-driven design. Before we move on to making the model more complex, and changing the model as we understand it better, let's first refactor this into Zest™ and discuss the immediate differences.

Steps;

1. Cargo has a size property. We change that to use the Property feature in Zest™.
2. Voyage likewise has the capacity and bookedCargoSize properties.
3. Zest™ doesn't need implementations of the Cargo and Voyage implementations.
4. Cargo and Voyage are entities, so we create CargoEntity and VoyageEntity interfaces.