Agile and domain driven design (part 2): Event Storming

by simbo1905

The last post set the scene for how an agile digital services team gets to the point where it is ready to cut some DDD code. Imagine that you just joined the team as a programmer as the programme is ramping up its private beta build out. To align ourselves to the demo code of the last blog series you are need to build out some stories about how customers and your internal users create and agree a contract to deliver products. You are an agile analyst programmer who wants to build a ubiquitous language with the users of the system. So you attend an event storming workshop with the users.

During the event storming workshop with the users the power of the post-it note comes into full effect. Users stick up notes that denoted business events onto a wall and move them around. There will be some duplication and overlaps and confusion as to the words used. That needs to be talked through as the team build up it’s ubiquitous language.

Arrows are drawn on post-it notes and an attempt is done to try to show a flow of events on a happy-path run through of what the most basic contract negotiation could look like. The users use language like “draft”, “bind”, “amend” and other business terminology. Pre-and post- conditions to the events are outlined. Bounded contexts are drawn and events that cross the contexts are noted as well as events that remain within a context. You take notes and mirror the language of the users. Contract negotiation is clearly identified as working with distinct “things”. Contract fulfilment is another distinct set of “things” where different users take over the work. It can get complex in that a contract may be amended in a feedback loop. Focusing on the happy path stops you falling into that rabbit hole just yet. Eventually everyone runs out of brain calories. Time to take a photo the whiteboard with your phone and email it to the group.

You now have a better idea of the key business events and intents of the users of the system. You have also identified that the contract is an aggregate, that products is another, and deliveries are a third. The pre- and post-conditions of events are outlined enough to start to build out some screens making some educated guesses. Armed with an understanding for the process you feel almost are ready to write some code but you have some nagging doubts around the exact business rules around contracts. You need a deep-dive session into that with the users.

The next day you get some users together to talk about contract business rules. On a whiteboard you start to draw boxes and lines and mark relationships with cardinalities. Its a bit odd to the users but they are willing you humour you as you draw a diagram on the whiteboard so long as you keep talking their language and talking through business scenarios as you try to draw a model. The users are happy that someone is so deeply interested in knowing the gory details of how contracts work. You rub out and redraw bit of the diagram as they correct you on “how contracts should work”. The final drawing looks this diagram:

root-objects1

With the users you write out the following list of business rules rules:

  1. contract has many lineitems
  2. contract has many deliveries
  3. delivery to a location contains some lineitems
  4. lineitem is a quantity of a given product within a contract
  5. lineitem can only be in zero or one deliveries
  6. Altering the lineitems within a contract updates the total cost of a contract

The users of the system agree with the rules. You go and write the code as an OO aggregate. That is an OO rich domain model that knows how to obey the business rules (aka enforce the invariants of the contract aggregate). The next question is where should this code run? What provides the surrounding workflow? Which screens, running where, drive this “thing”?

Advertisements