Why OO Business Applications Always Wind Up Splitting Methods from Data And Not Encapsulating Either

One of the main—perhaps the main—selling point of OO is Encapsulation. Which is actually two selling points. Firstly Information Hiding, that is, hiding the innards of a class so you can use it without needing to know how it works. Secondly Modularity, holding related data and methods together in one place. It's the use of objects & classes to achieve these two effects that gives OO a large part of its flavour, distinct from procedural or functional programming.

The power this gives is the ability to model the domain naturally. This is power of OO. Given a business having customers with addresses, orders, invoices, products etc, we can model the domain - the entities and their relationships - very naturally in code by creating classes to represent them.

So as OO developers coming to line-of-business applications we expect to apply these techniques. We think about what should be private or public to each class, and we think about what responsibilities belong with classes, and what methods & data are needed to fulfil that responsibility.

The problem is, businesses don't do modularity and information hiding. (Well they do of course, by being split up into business functions - sales, accounting, warehouse, customer services etc. Information private to one department is not usually available or even of interest to staff in another. But that's not the level we're interested in in a domain model).

Look again at our OO classes: customers, addresses, invoices, orderlines, products etc. These things are not encapsulated in business use at all. Firstly, there is no hidden information; when a business user goes to their information system to get information about a customer they expect just that: Information. No hiding. Secondly, information is all they expect. They do not expect the information system to model the customer's ability to Walk() and Talk(). No methods - and so little modularity - are needed.

This is true of almost everything in a business's domain model. From a business users point of view, it's all just screens of information. Documents. And this - the humble document - is the heart of what we missed in our sketch of a domain model. The real thing we are modelling is not the flesh and blood Customer, or the physical Product they want to buy. What we're really modelling in line-of-business apps is paper documents in a filing cabinet.

A piece of paper in a filing cabinet has no methods to model. It's just a data-holder. An accurate domain model for a piece-of-paper-for-a-customer is just a list of fields or properties. You can wrap get() & set() methods round them if you like, but all you're doing is adding boilerplate. (As an aside, a big advantage of computers over paper is much better performance in modelling relationships between those pieces of paper. A database can look up a customer's order history much faster than a human with a set of filing cabinets).

So where are the methods in a business? They are largely in the business processes. (The phrase 'business process' is one that your business people use, which tells you that business processes should be part of your domain too).

To the business, a process is usually a sequence of actions done by a chain of people. In a typical business process, a piece of paper (actual or virtual) is passed around; information is updated on it, or on other pieces of paper; and very occasionally something is actually done, such as finding an item in a warehouse and putting in a box.

Which class in your domain is responsible for these actions? Probably none of them. You could create a WarehouseWorker class responsible for Pick()ing and Ship()ing the product, but you'll quickly realise (unless your warehouse is staffed by robots for whom you are writing the control programs) that you can't write any code that actually belongs in those methods. You can write code for UpdateStockCount(), to record the fact that stock is decremented; and you could write an UpdateCustomerOrderStatus() so that the customer services department can tell the customer how their order is getting on. Indeed, that's probably exactly what's being required of your system. But which class in your domain responsible for these actions?

If you think that the Customer class, or the Order class, is responsible for UpdateCustomerOrderStatus(), then you would appear to be imagining a piece of paper updating itself, which is not a normal responsibility for a piece of paper. (Either that, or you're imagining the ghost of the customer coming on-site to keep track of their order. The real customer has no such responsibility. Their only responsibility at this point is to sit at home waiting for their package to arrive). In the world before computers it was probably the responsibility of the Stock Controller or Inventory Controller (yes, those are real job titles still held by real people) to do this book-keeping. So your domain model could/should include a StockController class with that responsibility.

Now ask yourself, what data do I need to encapsulate in the fields of a StockController class? The answer is almost certainly none whatsoever. You are not usually asked to model the real stock controllers' working hours or height or physical strength in a line-of-business application. All you need to model is their ability to UpdateStockCount() & UpdateCustomerOrderStatus(). You need model no internal state.

This is typical of business process modelling. Business processes are nearly always stateless - all the information they need is given to them each time they are invoked. This is true for so-called 'long-running' processes too: the classes responsible for performing each step of the process are not responsible for holding state. Rather, they expect to have data (or ids/keys to look up the data) passed to it.

In short: ninety percent of the domain of a line-of-business application is usually correctly modelled as:

  • Documents holding data
  • Stateless public processes which receive these documents as their inputs

Because most of what you are modelling is paper documents (which do nothing, except record data) being worked on by employees (about whom you know nothing, except their ability to update the documents).

And that's why data is not encapsulated in business applications, nor are methods and data held together in the same class.

Objections

But wait - surely we still have encapsulation and information hiding between for instance the UI layer vs data access layer vs domain model?

Yes, that's right. The StockController exposes the fact that it can UpdateStockCount() but hides the fact (in fact, doesn't even know itself) that this is achieved by writing to a copy of SQL Server installed on machine XYZ. A clear sign of concerns that should be separated at quite a high level is that they are semantically unrelated, that is, they speak a different language. The UI layer and the domain model know nothing of this 'Sql Server' of which you speak.

The point is rather that you should not be disappointed if it turns out that your domain model feels more anaemic than rich. That models the reality of typical business domains.

What about business rules & logic? They aren't stateless business processes?

Also true. And the above line of thought need not be applied to them. (Does an abstract concept such as 'business rule' have state? Yes if it's the-rule-as-applied-to-a-specific-case; no if it's 'The Rule' in abstract).

2 thoughts on “Why OO Business Applications Always Wind Up Splitting Methods from Data And Not Encapsulating Either”

  1. Thanks Chris for discussing this important issue. As you, I see many modellers wrestle with this. However, the direction you seem to have taken (stateless interfaces and public state if I may summarise this way) although well argued, still seems unnecessary. I know (as you do, as I deduce from your sound reasoning) that it counters the rule of OO design as well, but that is not the source of my unease. That source is that the kind of solutions you create in this manner are not innovative or supportive for new ways of integrating business and IT. They reflect the “old” way of doing business. As you explain: with documents and long-running processes detached from those documents. Could you agree that it is possible and potentially rewarding to model the business in a different way, more in line with the actual complexity of intertwined businesses and customers, for which the “traditional” rules of encapsulation would apply because there is no other way to model all that complexity in a manner that is flexible and manageable? And that these models would provide real and even much added value?

  2. Hi Rob,
    Thanks for dropping by! Do please say a bit more – or point me to a link? – about “new ways of integrating business and IT”. I agree that my line of argument leads to something that is not innovative. But I do think it supports moving forwards, because the best starting point for modelling the business’s evolution from today to tomorrow is … a model of today’s business. And the innovation that gets us to tomorrow has to happen first in the enterprise architecture & the business processes before we express in application design & code, doesn’t it?

    Do you think the description I’ve given of the way a “typical business” (as if there were such a thing!) works is wrong? If so, then yes I’d agree with modelling it differently. I’ve based the above largely on small/medium businesses where I’ve worked the past few years.

    I think “modelling the *actual* complexity of intertwined businesses and customers” is definitely right. “Model what’s *actually* there” is imho the OO prime directive. Either that or ”match the user’s mental model”
    Chris

Comments are closed.

Why OO Business Applications Always Wind…

by Chris F Carroll read it in 6 min
2