One of the most difficult parts of becoming eventually consistent is getting people out of the mind set that everything is always consistent. Years ago before they introduced their system that used to be legacy that everyone now can after over a decade finally laugh about; they probably ran with paper (or maybe they ran with scissors who knows). Paper was awesome because it never gave the impression of global consistency and it is the thinking that went into the optimization of paper processes that can help us optimize our transactional systems.
Then again getting to that point can be tough so we will focus more on that in the next post … For now we will look at getting through the barrier of assumed global consistency.
SME: So yeah this <data, let’s call it a purchase order> is edited by the user and can be searched by others or viewed in our reports.
Me: OK, how long of a period is generally acceptable between the time that they enter the data and the time others can see it, is it different for reports vs searches?
SME: It should be available for all of those things immediately.
Me: The “purchase orders” sound pretty important, what happens when part of the system goes down? How long of being unavailable would be considered a catastrophic failure?
SME: Well in our current system when things are down everything is down so I can’t say that we have dealt with that but 30 minutes of the current system being down and not being able to enter purchase orders would cost our company $237,123 in lost productivity and possibly lost orders (of course they have spent the time of analysts to calculate this exact number but they have never really tried fixing the problem before). This is why we are rewriting the system.
Me: Entering purchase orders sounds like it is the life blood of your business; is that correct?
SME: Of course without purchase orders we have no business!
What has happened here is that we have turned the conversation from everything always being consistent to discussions about the needs of various parts of the system in terms of risk management. Talking about what should happen when things go wrong in the system is a very effective way of turning the discussion away from global consistency as global consistency generally means global failures.
Me: What if you could still enter new purchase orders but you couldn’t run your daily sales report? How would that impact your business?
SME: Well our managers might have to revert to the former manual process of taking all the printed copies of the “Purchase Orders” and adding them up in a spreadsheet. We could probably even deal with this for a few days but not more and it couldn’t happen often.
Me: How timely does the data need to be on the report? If the data is two minutes old but was correct as of two minutes ago how would that affect your business.
SME (laughing): Awww hell, not at all those lazy managers generally print the document and stop at the water cooler for at least 10 minutes before they get the printed document.
So we have very different architectural requirements for two parts of the system. This is one way of putting things into Bounded Contexts by identifying architectural requirements upon the data. We have realized here that the thing that gets the data for the Daily Summary report should not be in the same Bounded Context that manages purchases orders because they have drastically different requirements. We could have also come to a similar conclusion by using CQS (command/query separation). Generally speaking you will find not one but many reasons to put data into a different Bounded Context or Parallel Model when you only find one reason to do so you should question whether or not it should actually be segregated.
Me: What about the searching for customers to add to Purchase Orders i.e. to lookup Discount information, what if only that one part failed.
SME: We would still need to be able to look up information like that in order to function.
Me: Ok, let’s talk a bit about how that information gets entered and changed in the process. As an example, I am a new client what happens.
SME: Well your company would make arrangements between sales and account receivable. We would establish a credit line for you and setup any agreed upon discounts.
Me: Ok does this generally happen in a few minutes? What is generally the time from accounts receivable getting the person setup with a credit line?
SME: Well that can vary, usually a while but sometimes right away.
Me: Right away in a human sense or a computer sense?
SME: Right away in the sense that after they get setup they may be transferred back to sales to make a purchase.
Where is this going? What sorts of things are we learning about the domain and how things interact?
The introduction of talking about how long things should take in terms of SLAs between contexts/models provides us with a lot of detailed information about the domain even if we do not intend to use it to provide SLAs within our system. As such we as DDD practitioners should be introducing this type of discussion regardless of whether or not we intend to move towards messaging.