Saturday, October 18, 2014

The 4 Aspects of Every Application: Part - II

The first part has to be read and understood so this post can be understood in that context. 
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