Agile and domain driven design (part 2): Event Storming
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 the rabbit hole of alternative and exceptional workflows 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:
With the users you write out the following list of business rules rules:
deliveryto a location contains some
lineitemis a quantity of a given
lineitemcan only be in zero or one
- Altering the
contractupdates 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”?
About exceptional workflows: One thing to beware are subject matter experts who delight in complexity. I remember a classic case of a product owner who was the ”IT geek” of the business area who wanted to solve a very complex cornercase in the system. It was one that the legacy system didn’t handle very well. Solving it automatically and showing the complexity on the screens would have had a huge impact on the system. When we spoke to the operations team lead who would own the running service they opined that they would not trust what the system did in rare corner cases unless they worked out the answer in Excel and had it double checked. It was decided that the operational process would be that a signed off Excel sheet would be applied directly into the database. We avoided all the complexity of building screens and business logic that could automatically handle rare and ill defined corner cases.
About building the happy path: Many business users are used to IT over promising and under delivering. This can lead to a behavior that business users say every feature is critic priority and demands that all the alternative workflow are delivered in the first release. To combat this build only the skeleton of the happy path and deliver it very quickly (my aim is to get something tangible, deployed and running inside of three sprints). Then incorporate user feedback in the next sprint. This will build trust and the users will then properly engage with the agile process and follow agile practices such backlog grooming and prioritisation.