Business Object

I have a confession to make. I'm unconvinced about the humble BusinessObject.

My understanding, however limited, is that this is an object that is supposed to reflect a real-world object. An Account object, in the banking domain for example, is likely to provide facilities for depositing and withdrawing funds and returning the current balance. The "BusinessRules" are encapsulated within the object.

Unfortunately, when this BusinessObject is created (using YouArentGonnaNeedIt) its scope will be limited - providing necessary services for only one EnterpriseApplication. The BusinessRules will only have been coded for that application.

Also, the BusinessObject is likely to be coupled to some kind of Data Access Layer for interacting with the RelationalDatabase.

The trouble begins when this BusinessObject is to be used in another EnterpriseApplication and then another, and then another, ... And, of course, each application has different needs. And the BusinessRules are also different - one application wants to be able to use the concept of an overdraft, the other doesn't. I see a StrategyPattern coming on. And this where the BusinessObject concept starts to break down in my mind. Probably because I haven't ever seen a really good definition of what this thing really is.

Yeah, yeah. I hear you saying these are othogonal concepts. The evolution of an object across applications and the actual concept of BusinessObject. But whenever I've had people talk to me about a BusinessObject I think they're implicitly thinking about the evolutionary aspect. Not sure.

And we haven't even touched on the non-domain concepts that are likely to proliferate an EnterpriseApplication. Things like transaction control, logging, security mechanisms.

And then there's how the UI presents the BusinessObject information. Negative balances in red with brackets, etc. These rules are stored somewhere else again. Oh dear.

What are peoples' thoughts on the BusinessObject and its applicability to large Enterprises that contain multiple applications? I hope, as a start, someone can provide a precise definition. I know the above is a bit of a rambling mess, it needs ReFactoring. --DanGreen

;-----

'BusinessObject'

Responsbilities Contains the data, BusinessRule's and accessor methods required to represent a real-world object in software.

I think _encapsulates_ the data is a better term than _contains_. For instance, a BusinessObject may actually hold one or more DataObjects? that map to a row in a relational data base and perform an object-relational mapping. In this case, the BusinessObject provides an specific view to the data which makes sense to its clients. However the same DataObjects? might be reused by other related BusinessObjects that provide different views. The point is that the data containment role may actually be held by simpler objects than the BusinessObject in order to simplify data access and data reuse. -- RomanStawski?

ToDo: Confirm that it seems a BusinessObject is primarily a DataObject? that also contains logic for validating input.

I respectfully disagree. A BusinessObject (a.k.a. DomainObject) is a reification of some abstraction that is important in the problem domain, and that likely implements meaningful, computational behaviors in addition to semantic validation logic. For example, in FoodSmart, a Recipe knows how to compute the nutrition profile of a serving of itself, based on the nutrition profiles of its constituent foods - which algorithm involves computing how many servings of each food are represented in the ingredients specifyng them, then summing for each nutrient across ingredients, then dividing by the nuber of servings - being sure to correctly convert units all along the way. See below some definitions from literature. --RandyStafford

ToDo: Confirm that the input should be passed in using ArgumentObject's as described in JamesNoble's ArgumentsAndResultsPattern. Moreover, the ArgumentObject's should contain DynamicProperty's (see the DealingWithProperties? pattern by MartinFowler for details) for maximum flexibility. This allows the BusinessObject to be independent of any particular GatewayObject (eg. web form, win32 client application or XML data). However it does place extra burden on the client to map the data to the format required in the ArgumentObject. And if DynamicProperty's are being used this sacrifies design-time type checking, etc.

ToDo: Confirm that the responsibilities of this object are not to be confused with a ControllerObject? in the ModelViewController pattern. The ControllerObject?, in turn is likely to be plugged into some complex WorkFlow.

See also: WhatsaControllerAnyway. Unfortunately from the Smalltalker's perspective, the meaning of "controller" has become lost as MVC (ModelViewController) has increased in popularity as a buzzword. --RandyStafford

Collaborations Other BusinessObject's, DataAccessObject's, ArgumentObject's

Views, Controllers, ServiceLayer?'s, PersistenceLayer's. --RandyStafford

</ReFactoring end>

-- DanGreen

This same topic came up on EJB-INTEREST a while back. Which compelled me to make this posting, quoting some definitions from literature:

The best treatment of DomainObject's I've seen in literature is in Chapter 11 of TimHoward's book TheSmalltalkDevelopersGuideToVisualWorks. There is also a book BuildingBusinessObjects? by PeterEeles? and OliverSims. Here is a contrast of their definitions of terms:

Howard: "a DomainObject is a logical container of purely domain information, usually represents a logical entity in the problem domain space ... In general, DomainObject's should know how to recognize which [of their] references indicate aggregation and which ones indicate association, copy themselves, maintain business logic, compare themselves to other DomainObjects of the same type, facilitate other objects that choose to print or display them, and conduct tests on their domain information [to which I would add validate themselves]".

Eeles & Sims quote the OMG definition: "a BusinessObject is defined as a representation of a thing active in the business domain, including at least its business name and definition, attributes, behavior, relationships, rules, policies, and constraints."

Mix the two definitions together and you might have something useful (I'm not convinced all BusinessObject's must have names, "definitions", "rules", "policies", and "constraints").

--RandyStafford