Business Primitives (1/2)

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.

About Dru Sellers

Sr. Software Engineer at Dovetail Software.
This entry was posted in Small Ideas. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://www.yawmark.com Steve

    Great post, Dru. I believe this sort of business-oriented mindset while developing is just as important as other design-related considerations.

  • Jason

    Am I missing something? This seems to me to be another way to define value objects within the context of the business?

  • David Denton

    I’ve been using business primitives (aka MicroTypes aka Tiny Types) for a while now and I have to say that personally I’ve found it to be the most valuable pattern (dare I call it that?!) that I’ve used in a long time.

    Domain code just seems to fall into place – all those little functions have somewhere to go and the code becomes much more elegant. I can also recommend controlling the construction of the business primitives using static methods (with a private constructor) – when combined with a strong IDE (such as Idea), speed of coding is vastly improved.

    e.g. pricing 5 units of a product could be written as:

    cost = product(“fish tank”).costOf(units(5))

  • http://thinkbeforecoding.com thinkbeforecoding

    I always try to use as few primitive types as possible.

    Primitive types should be used internaly at the infrastructure layer but should appear less frenquently on upper layers.

    Creating such types give a clear meaning and provides only operation that can make sense. (Identities cannot be added etc..)

    But this can kill the use of some technologies… Linq to Sql doesn’t manage the mapping of such objects, you have to remap everything in other objects everytime.

  • http://www.codeofrob.com Rob Ashton

    We’re currently doing something similar, using home-baked value types to represent concepts within a system that would ordinarily just be a string.

    We can’t get away with using enums because we don’t know the values up front, so tend to create classes whose sole function is to represent a value, and have a factory to get those value types when going to/from our persistence layer (NHibernate).

    It can be a bit tricky at times though, so I’d like to see how you end up writing about this in your next entry *hint* :)

  • zihotki

    Wow, the idea of using business primitives instead of standard basic types is great and useful. I have never saw such approach but it makes development much more easy. Thanks for sharing it.

  • http://www.josheinstein.com Josh Einstein

    Great post. Paul Stovell recently wrote about something I am very fond of – creating structures and classes that are simple constraints on strings or other primitive types. A perfect example of this would be a phone number which does have parts, does have rules, can be equal with different string representations, etc. Yet it is implicitly convertible to string.

    Unfortunately, it’s just very tedious to get these types “right”, requiring proper handling of Equals/GetHashCode, ToString, operator overloads, etc. Then there’s the matter of implementing IFormattable, IComparable, ISerializable, etc.

    Then once you’ve done all that, many things like WPF/Silverlight/LINQ/etc will simply blow up if they encounter one so you need to write an IValueConverter/TypeConverter, perhaps a custom DataGridColumn type, etc.

    Anyhow it’s definitely a good thing if you find the time to do it. I’ve been playing with T4 templates which have allowed me to create consistent implementations with minimal effort. Once I clean it up I’ll post about it.

  • Michael Chandler

    I’m looking forward to part 2. This is definitely something that I don’t spend as much time on as I should. I’ll now make a conscious effort!

  • Daniel Fernandes

    I don’t think those primitive types sole existence driven by UI binding requirements, the examples you’ve taken all lead to single value natural identifiers that can be easily compared for equality.

  • http://blog.troytuttle.com Troy Tuttle

    Nice post. I think a lot of us battle the primitive data type demons from our data-driven development days, when everything boiled down to a SQL Server data type for storage. That thought process is often translated to OO development where it doesn’t really belong.

    Looking forward to your next post!

  • http://www.adverseconditionals.com Harry M

    I totally agree that people overuse primitives as properties on their entity classes – by having a class to represent User.EmailAddress or Team.Members you can add really handy properties like CanEdit, CanRead which you can use to drive the UI.

    Another thing you can try, on a similar(ish) vein is to switch your Id properties from ints to enums, e.g. a UserId enum (without named values). If you are passing integers around on method sigs, it can be nice to give em a type to avoid putting the wrong value in the wrong place.

  • http://codebetter.com/members/Ian-Cooper/default.aspx Ian Cooper

    Great topic. Chaging parameter types away from primitives to domain concepts is something I’m really keen to tackle. Looking forward to the next part.