Understanding the business has been stated time and again as being an important part of the development process. In order for me to better support the business one of the ‘little’ things that I am finding greater and greater love for is the ‘business primitive’, a very small object, often containing only a single field, that completely encapsulates one small, well defined idea of the business. This is most often a specific type of data, like ‘Money’.
This does a couple of things for me right off the bat. One, my methods can now ask for these ‘business primitives’ rather than a language primitive which means there is more meaning in my methods so that they need less documentation and that I am less likely to pass the wrong string into the wrong position on a multi-parameter method. Two, I tend to stop talking in ‘developer-speak’ and start talking in the language of the business. “Ahh, so an Instrument is identified by a CUSIP!”
This is also a very easy way to start experiencing the benefits of DDD’s ‘Ubiquitous Language’, as you build up a collection of business primitives your ability to discuss the business problem with the business people in the terms of the business should improve. After all, your business partners don’t think in terms of ‘strings’, ‘integers’, or ‘booleans’ rather they think of their business process in terms of ‘real world things’ like ‘Loans’, and ‘Investments’ and most complex things are built up of smaller objects like ‘Money’, ‘InterestRate’, and ‘CUSIP’ your company’s concept of primitives.
As the use of business primitives grows, your understanding of the business should start to stabilize, and should gain some sense of consistency with the business. For instance, if you have a ‘Money’ class then you have a perfect location to deal with money rounding issues.
If you find that this would be hard to start doing, I find that it is easier with primitives that are defined outside of the business itself. For example at the bank there is a concept of a ‘CUSIP.’ This is a industrywide identifier used to identify financial securities. It has a set of rules about how it can be composed. (http://en.wikipedia.org/wiki/CUSIP). You are going to have to conform to these standards anyways you might as well put all the rules in one place.
If you are familiar with DDD then I also want to be clear that ‘business primitives’ are VALUE TYPES, like a string or an integer, their value is their identity. One instance of CUSIP ‘CUSIP 912827XN7′ is equal to (==) another instance of CUSIP ‘CUSIP 912827XN7′, which makes sense, their identity is their value. This is distinctly different than the DDD ENTITIES where they are not equal based on the their values, but by their ID, so ‘Loan’ with value $100 would not equal another loan that also has a value of $100.
In closing, why is ‘primitive envy’ (the overuse of programming language primitives in place of real objects) such a pervasive problem? I think that it has a lot to do with UI control binding. When we are building some of our first programs we need to send a string to the screen so we can see ‘Hello World’, we don’t build out a ‘Message’ object and then send that to the screen through a ViewModel abstraction. But these behaviors that we build early in our careers can be a deep seated habit that is hard to break out of. Its just too easy to think about the UI and that its going to need a string for the name text box, and then code the ‘name’ as a string in your object. So push back, reclaim so OO love and work with your team to build some real business primitives.
My next post will show how we can implement this process.
