The Domain Driven Design Parcel Service is a small competitor in a hugely competitive market. With such competitors as UPS, FedEx and DHL, we are at a competitive disadvantage, and need a solution to cover our interactions with our customers, and to streamline our internal processes. This software will be at the heart of our expansion plans and needs to grow as the business does. Although we are currently only a national carrier in the UK, our long term vision has much wider reach.
The Domain Vision Statement (Evans page 416):
The DDD Parcel Service Booking Domain is to be responsible for Customer interactions. It should reflect the processes and practices our Customers want to use. This should reflect the relationship we want to have with our Customers, and easily allow them to deal with booking processes, managing their accounts with us, our discount and promotion schemes, and allow them to see a historical record of their business with us.
And So It Begins
I needed something concrete to start putting some of the concepts from this series into, to try and show how the patterns of DDD can be used in a “real” code base. In addition, I have spent a long time thinking about the specific domain for the example application, as it had to be something that had real meat to it, and real behaviour.
I could have gone down the shopping site route, but expanded it to be more like Amazon than a small one man operation – but as shopping sites have been done to death I had to find something else. Unfortunately the original example application for DDD also exists in a similar sphere to my choice. I did consider this carefully, and have weighed up many options.
The domain chosen had to be:
- Easy to understand when you put yourself in the shoes of the business
- Easy to understand when in the shoes of a customer of that business
- Simple enough to not get swamped in technical details
- Complex enough to show a number of aspects around the things DDD brings real benefits to
- Have real behavioural process rather than just another database and a pretty UI
In addition, I had to be able to deal with the domain with little friction – although it may have been fun to learn some of the domains that various people suggested to me (including the Oil Drilling Industry!) – I only have a limited amount of spare time, and my girlfriend has a big priority on most of that.
The DDD Parcel Service fulfilled all of my simplicity and complexity requirements, it is a pretty common domain to most of us in everyday life, at least from the Customer perspective. It also happens to be a domain that I have touched on in the past from a business perspective.
It happens that with my choice of a Parcel Service domain I had easy access to a Domain Expert of sorts – my girlfriend has a long family history in the haulage business, and on a daily basis manages the haulage for a customer just like those that the DDD Parcel Service would have.
This Morning’s Progress
Despite both myself and my girlfriend suffering bad colds, I pinned her down for 20 minutes to start the first session on extracting some of the user stories for the DDD Parcel Service
I then started hammering away at a few screen mockups in Balsamiq … and I think on that point I’ll start a new blog post for tomorrow or the day after.
So Where Is The Code?
Don’t be in too much of a hurry! I have started a project, and have the core framework starting to form up. But more importantly to me, and to DDD is the design, the extraction of the UL, the agreement of the User Stories, and the way we get to the code. Over the next week or so I will try and start turning the initial stories into a beginning code model – and at that point you can all rip it to pieces!
03-07-2009 7:08 PM