Artificial vs Natural Attributes
Through the years of developing business software, domain representation has always been the most exciting aspect of the job. Not only has this empowered me to write better software, but to also assist in a small way in helping business owners better understand their own business processes. The following is an article involving how to best represent properties of business objects and communicate these ideas to clients which are usually non-technical by trade.
We are going to work within a hypothetical relationship. Our current client Jane Doe owns multiple car dealerships. We are building software that will allow her to track inventory, so the system logs the vehicles when they are purchased, tracks maintenance and detailing, then the sale of the vehicle. This sounds like a fairly simple software package, but like all software, the cost is in the details.
Jane asks, “I need the ability to track if a vehicle has been detailed before. We detail vehicles every so often because of rain, snow, and just dirt in general from being on the lot.”
Myself, “Well since we have a table in the database that tracks maintenance, we can use that to know if a vehicle has ever been detailed. If there are any entries of maintenance, we know it has, if not, it hasn’t.“
Jane responded, “So do we have a specific field that represents if the vehicle has ever been detailed? We need this because vehicles that have never been detailed are prioritized to get them on the lot as soon as possible. The lot managers get a report in their email every morning to know the status of the vehicles and how to manage the inventory.“
Myself, “No, there is no specific data point stored in the system. This is because whether a vehicle has been detailed is a derived property of a vehicle. So basically, you can say the car is red because if you look at it, it is red, there is no other information needed outside the vehicle to know what color it is. However, for us to know if the vehicle has been detailed, we need a secondary piece of information outside of the vehicle, which would be our maintenance logs. So the answer to whether the vehicle has been detailed, is are there any entries in the maintenance logs that say it has.“
Jane’s response, “So the report we send out will say if a vehicle has been detailed before, but that is not a data point tracked in the system, but an expression of if a maintenance log exists?“
Myself, “Exactly, just like an employee would answer this question by looking at the maintenance logs, the system will do the same. The goal of the software is to simulate your business process, not change it. If we add an artificial property in the system, then it would have to be kept in sync with the maintenance logs, which can become a nightmare in itself.“
Jane, “Ah, that makes sense.“
As you can see the discussion is really about how to represent if a past event has occurred in a system. A single event cannot be represented by flipping a bit from false to true, without introducing an idea to a business model that does not exist in reality. That breaking from reality creates a domain model that will in essence invent artificial scenarios that the business will have no solution for because they don’t actually exist. In essence, there is no concept that a vehicle has been detailed before, but has no entries in the maintenance logs. The maintenance logs are the authority for if a vehicle has been detailed, which is why this authority should exist in the domain model.
I hope this entry is useful and sheds some light on the types of conversations that should be happening with clients in constructing their software. A good rule of thumb is to understand in most business software, all of this could be done with paper and pencil, at some point in history it probably was, software is nothing but the automation of those classical processes, nothing more and nothing less.