The
business-object-oriented applications have at a minimum 4 aspects: Business,
Process, Maintenance, and Infrastructure. These are not
full-blown design patterns of the
GOF variety, but rather patterns of design for a single object.
The impetus
here is that for a singular concept, there are four aspects of our applications
that have to deal with it (This is only untrue when our application’s
total emphasis in on just one of the aspects. I think that is rare, but either
way these objects are in the context of the common
business application where
all 4 are usually in full swing). As a firm believer in a separation of
concerns,
encapsulation, and cohesive objects that do one thing well, I often end up with
different objects for each aspect as opposed to one object that does
everything. This leads me to answer the question then: What do I want from a
class in order to fulfill a particular aspect.
In each case
below I refer to a business or domain abstraction. I don’t want to use the term
“object” or “class” since the whole point here is that many classes might represent
the same abstraction. So to be clear, in a blending application a Blender is a
business abstraction that might be represented in code by multiple
classes.
The Business
Aspect
In this case I
will want an immutable class so that it is automatically thread-safe and has no
synchronization issues. This immutability will also ensure that this business
object will not have to worry about the effects of changing state, worry about
being invalid at any time, or be concerned about being changed by outside operations.
Aside from immutability I would expect that this class’ design would ensure
that every method of the class is directly related to the business of that
class…in other words, cohesive in respect to its business. More so than other
classes, encapsulation is of the utmost importance as we want to know where all
business logic related to the data of this class is located. Exposing any
property (data) would be strongly questioned. This class would provide an
interface to work with relationships that have to do with the business. Any
changes to business rules and logic affect only this class.
The Process
Aspect
In this case I
need a class that encapsulates a process that is directly related to an
abstraction in the domain. Its code base would be very thin as it would only
layout the flow of the process but not be concerned with how anything gets
done. Its methods would have to do with the process alone. This class might
have to have feedback mechanisms or methods that help outline steps in the case
of user input that is required along the way. This class’ design would ensure
that every method of the class is directly related to the process the class
handles…in other words, cohesive in respect to the process. Any changes to
process flow affect only this class.
The
Maintenance Aspect
In this case I
need a class or classes than can help me with the general maintenance of a
business abstraction. More often than not this is simple CRUD stuff for the
abstraction’s data. This class might be mutable if a partially
built object makes sense. The methods of this class would all be directly
related to the maintenance of this business abstraction, in other words,
cohesive in respect to maintenance. This class would provide an interface to
work with relationships that have to do with maintenance only. This class’
design would also be less encapsulated because its purpose is often to work
tightly with the data behind a class. Any changes to validation or
other maintenance rules affect only this class.
The
Infrastructure Aspect
In this case I
will want classes that handle the fact that a given domain abstraction is being
represented in a software application. There will need to be infrastructure in
place so a domain abstraction can, for example, be persisted in and reconstructed
from a database. Because of the nature of infrastructure these classes may not
have any state, but rather just act as a library of functions. Any changes to
infrastructure affect only these classes.
No comments:
Post a Comment