The 4 Aspects of Every Application: Part - I

Application Point of View

I think nearly every software application project can be thought of as having the following 4 aspects: Business, Process, Maintenance, and Infrastructure. How you design your application has a lot to do with your point of view and which aspect you think should get the most emphasis. A common mistake is to view every application from the same point of view and thus one aspect gets the most emphasis every time. The aspect you give the most emphasis to will obviously affect every facet of your design including your object designs.

Business: This is code concerned with applying business rules and logic to determine what needs to happen in a given situation.

The result is a business-oriented application, one where the most effort is in making sure the business is correctly modeled and understood. This emphasis is valid for the common business application where a developer is trying to mimic a business as described by a business expert. A telltale sign of a design effort that is focusing on the business is that the main artifacts of design are business object models. Often the first thing designed is a rough sketch of the business entities represented as classes.

Process: This is code that implements a process which when completed accomplishes a required goal.

The result is often, as the name implies, procedural code. Or at best, the result is an object-based design where objects are used to hold data, but all the "thinking" code is in the process routines, not the objects.

Maintenance: This is code for the direct creation, changing and deleting of things in the application.

The result is generally a data-centric application where the business is viewed as just adding, removing and changing data in a system. A telltale sign of a maintenance application is when the design effort begins with designing database tables. From the very beginning the emphasis is off the business and geared towards the data instead. This kind of emphasis is valid for applications where truly the creating and changing of data is the primary focus. For example, something like a contact management application or some sort of activity logging application lends itself to a maintenance-focused application.

Infrastructure: This is code that is a result of the simple fact that we are writing software. Examples include code that maps objects to data and vice versa, security and logging for auditing purposes.

The result is often an application that does not model a business but rather reflects the implementation of the requirements. Often the goal of the developers in this case is to achieve something technically difficult. This kind of focus is valid for something like grid computing tools, framework libraries, etc. The business of the application is often technical in nature.

So what’s the point exactly?

A common mistake is to approach every application with the same emphasis in mind. I have found the most common mistake when designing the common business application is to design the application like it is a database-babysitting application.  In other words, the whole application is approached as if the business is all about Maintenance. The actual business logic is lost in the shuffle between inserts and updates. Furthermore, I think because business applications lose their business focus, developers who are intrigued with an object-oriented solution can't figure out exactly how to apply those OO principles to the multifaceted world of the common business application.

Value Object

Value Object (VO) is an object that is an attribute of another object without any identity relative to the domain and that can be interchangeable between objects that use the same attribute.

I have a Person and a Person has an Address. I have a Company and a Company has an address. The database may have a PersonAddress table and a CompanyAddress table. However, there is no need to create a PersonAddress object and a CompanyAddress object. A single Address value object can be shared by both the Person and the Company. All the logic related to an Address would be in that one place and can be tested without having a Person or a Company.

A value object is an object that often is used as an attribute of another object. For example, a Name object (value object) might be an attribute of a Person. More examples are Money, Point, Ranges like DateRange, Price/Quantity/Volume/Size Range etc.

A value object has no changing state and has no domain identity, it is not an Entity Object.  In other words, their lifecycle is not tracked in permanent storage.  For example, an address does not change, a person might change addresses, but the address remains the same. In other words, the person gets a new address.

A car might have the attribute color. Color is a value object. The system does not track colors. The car’s color may change from Red to Blue, but Red never changes into a different color, it will always be Red

Whether or not an object is a value object can depend on the domain.

Identifying that an object is not an Entity Object can simplify a design by making objects that are easily testable and not tied to what is ultimately a database that assigns identity.

Understanding VO can help us see objects where at first we just saw primitive data types: e.g. Person with Zip code value object instead of type string

Simple Exception Handling

I think any developer with any amount of experience would agree that one thing you do not skip, rule-bend, or even do poorly is exception handling. I would add that it can be tough to justify complicating error handling by turning it into its own subsystem with a bevy of objects and possibilities.

For what it’s worth here are a bare-minimum-yet-good-enough-for-most-common-business-application-development exception handling rules:  Do it, Be consistent, Keep it simple, Throw in the kitchen sink, Roll your own, Always at initial point of action

Do it

This is nonnegotiable, you use exception handling.

Be consistent

Be consistent across the solution. Everyone working on the project knows the simple rules and follows them in the same way.

Keep it simple

The simpler it is the more likely everyone will do it and be consistent. Make people justify any specialized exceptions.

Throw in the kitchen sink

Throw exceptions with every bit of data that could possibly be available to help the coder determine what happened.

Roll your own

Don’t call Parse on a type and let the code throw a “wrong format” exception, rather call TryParse and then throw in the kitchen sink when it does not work.

Always at initial point of action

Catch and handle exceptions at the initial point in the application where the system is sprung into action. In the common business application, this is often behind a button click or some other event handler for a user control. In other words, when a process (no matter how small) kicks off, wrap the call in a try-catch block and handle any exception gracefully. I often tell people that the only code in an event handler for a user control should be a try-catch block with a call to the action’s handler.

private void btnAddFileToRelease_Click(object sender, EventArgs e)

{

       try

       {

              TryAddingFileToRelease();

       }

       catch (Exception ex)

       {

              HandleException(ex);

       }

}

Notes

Unlike the old days, most modern programming environments provide a full call stack in an exception, so we know exactly where the routine bombed. Because of this we often don’t need exception handling all over the place. We need it at the initial point of action so our application stops gracefully and we need it when objects must be disposed.

Creating custom exceptions: Some coders seem to do this for every new exception they think of, often inheriting some base exception. This is poor OO programming to begin with even though it might look cool. A generic exception with a message that explains the unique error will suffice in 99% of the cases. Like many things I vote to keep exception handling simple before it turns into a subsystem all to itself that the next guy has to comprehend and maintain. Create a special type of exception if the code will behave differently because of the type. For example, if an exception is a network down exception, then the code might try again n-number of times.

Simple Exceptions: Often code “knows” the context of a call and thus might know that a user could fix the issue. In this case a special Simple Exception could be thrown. When the exception reaches the client interface the exception could be handled differently. Instead of logging the error and emailing support, a message could be displayed to the user allowing them to fix the issue before trying again.

For example, a system may allow users to define Widget Types and import Widgets into the system. During an import a Widget Type Key is read and the system looks up the Widget Type using they key. The code that does this could throw a Simple Exception if the Widget Type is not found.  The user would then get the message, set up the new type, and try the import again.

Just make sure your assumptions about whether or not the issue is user-addressable are valid. Often these assumptions that lead to Simple Exceptions being thrown are high on the call stack and not deep in the bowels of the system.

We can have just two kinds of errors, one for developers (Those that a developer needs to look at (and wants the kitchen sink)) and one for users (those that an end user can take corrective action for (given a much simpler explanatory message))

We should create specialized exception classes when the code behaves differently. So it would seem at a minimum we might have 3 types; regular, simple, and common.

Regular ones might get logged and emailed to the development team.
Simple ones might just get displayed to the user.
Common ones get caught and dealt with by code, like trying an operation again in case of slow network response, locked files etc.

It’s fine to start with just two types of exceptions and another one added for common issues that the code might be able to handle.

It may be a different case where a developer wants to explicitly state that a method may return one or more reasons why a process cannot be completed.

See also: On Exception Handling

Business Object (AKA Domain Object)

Business Objects are objects that correspond directly to concepts in the actual business the software is meant to represent and that encapsulate all decision making related to those concepts.

Often there is a chasm between how a business person perceives a business and how a software developer implements that business as software. Developers have to translate what is being said by a business analyst into the technology that is managing that business. Using object-oriented technology to create business objects representing the same structures business analysts speak of goes a long way towards improving the communication about and the design of an application.

Applications that represent a business are all about making decisions and providing support for users to make more decisions.  We try to have the code make as many of those decisions as it can. Examples include: Can a user login with this password? Can this Truck carry this Shipment? What’s that fastest route from Point A to Point B? The logic that determines the answers to these business questions is referred to as business logic. Business logic can be tough to figure out, easily done wrong, likely to change throughout the lifetime of the application, and is arguably the most important code written in an application. Duplicating this logic (on purpose or accident) is the source of much frustration and many bugs. Business objects are created to encapsulate this logic. The data used in these decisions are hidden away inside the object so no other code tries to make the same decisions, and no other code is affected when that data is changed to better support the logic.

There are many books and articles about how to come up with the best objects for a business, so I will not bother trying to sum up what volumes have been written about. In a nutshell, objects are created for any business concept that plays a part in the application’s requirements. All business logic is encapsulated in these objects, with each object answering the questions they are logically and usually best suited to answer.  For example, if user interface code wanted to know if a password entered is valid for a particular user then that code would ask the User object: user.IsThisYourPassword(password)

Business objects often cannot follow every heuristic of object-oriented design because of the nature of the common business application. For example, a standard OO tenet is that an object should not expose any of its data. However, in the common business application, business objects are created on the fly by administrators who need to see all that data. Attempts to uphold this rule without compromise can result in complex designs.

See also: What is a business object?

What are tiers/layers?

When someone talks about creating tiers or layers in an application’s design they are referring to grouping code based on their higher-level concerns. The most common and basic approach is to make three groupings of code: Presentation Code, Application Code, and Data Access code.  All code that has to do with presenting information to a user is in the Presentation Code, all code pertaining to the application itself (logic, brains of the system) is in the Application Code, and finally all code related to accessing a data store is in the Data Access code.  I may be starting to sound like a broken record, but the purpose of the layers is to maintain a separation of concerns.  This separation is also enforced in a hierarchal manner in that coupling between the groups of code is just one way.  This means that the Presentation Code references and calls code in the Application Code, but the Application Code does not reference or call code in the Presentation Code. The same goes for the relationship between the Application Code and the Data Access Code. And finally, the Presentation Code knows nothing at all about the Data Access Code.

Whether we refer to a grouping of code components as a tier or a layer depends on exactly how the code is being separated. When code groups are placed in different projects or systems where only the public interfaces are exposed to each other, then we would say the code is physically separated, each in its own tier.  When the code groups live in the same project and separation is provided by naming conventions, folders, or some other coherent way then we would say the project is logically separated, each in its own layer. It helps me to think of a cake where layers sit right on top of each other, but tiers are physically divided by plates and columns.

Presentation Layer/Tier

AKA: Front End, User Interface Layer, GUI (Graphical User Interface),

The presentation layer code is concerned with providing an interface for a user to work with the application. This code needs to be able to get information to a user and be able to collect information from a user. That is the extent of its purpose, its concerns. The actual “smarts” of the application, otherwise known as business logic, is not mixed with this code. For example, the presentation code may know that we need to allow the user to choose 2 accounts and a dollar amount in order to try to transfer money, but it has no idea how the transfer actually gets done, or what makes the transfer valid, etc. The benefits to this design are all the benefits you get from a separation of concerns, namely code that is easy to understand because it only deals with one thing (user interface interaction).

Application Layer/Tier

AKA: Business Layer, Domain Layer, Middle Layer

The application layer is full of code concerned with capturing the business of whatever domain the software is representing. This layer is the heart of the application, hence the name application layer. If the presentation layer only knows we need two accounts and a dollar amount to attempt a transfer, then it is the application layer that does all the heavy lifting involved with the actual transfer. For example, this layer might determine the accounts available for transfer, validate that the dollar amount is acceptable, actually coordinate moving money from one account to another, etc.

In an object-oriented or object-based design the application layer code is captured in what is commonly called business objects and or application services. Although it is clearly not the only benefit, a properly built application layer could have any kind of presentation layer put on top of it. For example the same application layer can have a Windows-front-end and or a web-front-end without changing anything about the application layer.

Data Access Layer/Tier

AKA: Persistence Layer, Data Management Layer, Data Layer

Often this layer is referred to by its abbreviation DAL. The data access layer is full of code concerned with Creating, Reading, Updating and Deleting data, otherwise known as CRUD. This layer works directly with a data storage device (most commonly a relational database system like Microsoft SQL server or Oracle database server.)  As with the other layers, it knows nothing of the layers “above” it. The DAL is an independently working system with the singular focus of data CRUD.

Beyond the basic 3

Often within the three basic tiers there are layers that are logically divided and placed in one of the tiers. For example, the data tier might return object’s specifically designed for transporting and stepping through data. Examples in the .Net world would be a DataReader or DataTable.  In the business tier we need to be able to take one or more of these data transfer objects and convert them into a business object. We don’t want to concern our business objects with this as it has nothing to do with the business. So a Data Translation layer may be created with classes that handle reading these data objects and putting the data into the correct business objects.

Data Translation Layer

(AKA: data mapping layer)

This layer of code bridges the gap between the data access layer and the application layer by translating data returned from the dal into objects in the app layer. Because of the tiered architecture and a separation of concerns, the domain objects know nothing of database technologies like RecordSets, DataReaders, and ResultSets. However, the code in the data translation layer does and is then responsible for taking data from these data structures and creating objects. This layer is for resolving what is often referred to as the impedance mismatch between relational databases and object oriented design.

Application Services Layer

AKA: Business Services Layer, Control Layer

This layer of code provides an interface for encapsulating processes the application completes. This is a thin layer of code that has no business logic aside from knowing what steps a process has or what is required of the process. All the thinking, the hard stuff, is left to other code, namely business objects.  The interface to the service layer objects are sometimes referred to as a façade since it provides a simplified interface to what might actually be communication amongst many other objects.

For example, the process of logging a user in to an application might require looking up a user object, validating a password, logging the login attempt, checking system access status, etc. However, this might simply require one call from the presentation layer to the LoginService. The methods in this layer often map directly to use-cases, user-stories, use-scenarios, requirements, etc. In other words, the public service methods often read like an abstract summary of what a system can do. Not only that, they are written in the language of the users and or business analysts. For example, a system might require someone to transfer money from one account to another. An Account Transfer Service would probably have a method called Transfer. If we looked behind the scenes of that method we would see the steps that are required: check security, validate amounts, transfer in, transfer out, log the event, and respond with completion message. The service knows what these steps are, but not how they are accomplished.

User Interface Controller Layer

The UI controller layer sits between the presentation and application layers. This layer is often used when the user interface is disconnected, like with a web application or is distributed onto a computer that is separate from the computer the application layer is on. Its purpose is to help facilitate communication between the layers without corrupting either layer. For example, imagine a user interface that requires four calls to the application layer to get all the information it needs to display itself correctly. On a desktop application we would not think twice about making those four calls. However, if all those calls were to an application layer sitting on a different computer (as is often the case with websites and other distributed applications) we might be rightfully concerned with the speed at which these things will get done.  We might want to make only one call that collects all the data together and maybe even converts the data into XML/JSON or some other structure that makes it easy to pass across the network. Making the four calls and massaging the data as needed for the UI would be this controller layer’s job. This layer is often considered part of the presentation tier, but it lives on the same machine as the application layer so it has instant access to the application code.

System Layer

A system layer contains code, often in the form of libraries that provide wrappers to common system needs exposed in common and an easy-to-use ways for our application. For example, there might be 6 classes and 12 different ways to read and write text files to the hard-drive in your programming language’s framework library.  A system layer library could expose a façade with two methods for the most common needs your application might have: ReadTextFile and WriteTextFile. When the new version of your framework is released and a class is deprecated or a new more efficient way to do something is released, our changes to how we do these common things are encapsulated and changed in one place. One example system class I often end up with is a StringLibrary class that has all the common functions I find I could use but are never provided like trimming a string that might be null, making a collection of strings into a readable list (Jakson, Miller, and Steve), check if string only contains letters, make first letter uppercase, removing dangerous JavaScript characters etc.

See Also: MVC, DCI, DCI Architecture, The Clean Architecture

What is a business object?

Business objects are programming structures that abstract the things/concepts in the business that a program is written to represent. These things should be recognizable to a non-technical person familiar with the business, like the users, business analysts, etc. For example, in a video rental store business we can assume there would be DVDs, VHS tapes, customers, rental orders, late fees, etc. In software representing that business there would be business objects that represent DVDs, VHS tapes, customers, rental orders, late fees, etc. Each object has data that describes or is attributed to the object and methods that act on that data. For example, a DVD may have a Title and DateReleased attributes (data), and may have the method “calculate rental price.” to determine how much it costs to rent the DVD.

These objects are tangible with real-world meanings, however, there are other business objects that are a bit more conceptual but still have a definite intellectual meaning like Rental Agreement or Rental Policies. These things are less tangible, but real-world none the less.

An object classified as a business object does not contain code to validate its data, store its data, build itself from data, etc. The smarts inside the object and methods all have to do with business logic

See: Business Object (aka Domain Object)

It’s the separation of concerns (SoC) that matters

If you take nearly any fundamental object-oriented concept and study its rationale you can tie it back to the benefits of separating concerns. The notion is simple really. It is easier to think about things, work with things, understand things and communicate things when we only think, work, understand, and communicate with the least amount of concerns as possible. And the goal of an object-oriented approach is to make complex things easier to think, work, understand and communicate about. 

We do it all the time in real life. If I spill a drink and the liquid is about to hit my laptop, I might quickly ask my wife for “something to wipe” this up. I don’t care if she gives me a paper towel, a dish cloth, a hand towel, or the shirt off her back. I am not concerned with details of the item she gives me. I only care that it can wipe something up. Likewise, I don’t quickly ask my wife for a “piece of absorbent cloth or paper used for wiping or drying and probably made in Mexico” either. She is not concerned with those details, she only needs to know I need “something to wipe” with.

Let’s take the concept of abstraction. In a nutshell it is the level at which we identify the details of something. A high level of abstraction means that when we are thinking, working, understanding and communicating about 5 things we do not have to be burdened by the details of those 5 things. A low level of abstraction would mean we are knee-deep in the details.  An object-oriented language has built-in features to help us write code that can work at the highest level of abstraction possible so we only work with the least amount of details possible. In other words, we only have to be concerned about very few details at a time.

By working to separate our concerns we end up with good abstractions. In object-oriented land this comes to play in abstract classes that are designed to define very general details of more specialized classes. For example a Towel is more abstract than a Paper Towel or Cloth Towel. When I wanted to wipe something up earlier a Towel is all I needed, I didn’t care if it was paper or cloth. In that case I could work at a higher level of abstraction, the details of the towel were not important in that scenario. If I write a routine to wipe up milk, that routine would take in a Towel as a parameter. You could call my routine regardless if you had a paper towel or cloth towel. If you one day get yourself a hemp towel, you could pass that in too. If I write a routine to wash a towel the routine might take in a Cloth Towel parameter because now I am concerned about a few more details, namely that the towel is made out of cloth.

Interfaces are yet another device that helps us separate concerns and allow us to be troubled with the least amount of details as possible.  If all I am concerned with is that a thing can be used to wipe up, then our routine to wipe up milk might not take in a Towel, bur rather a Wipe-Liquid Interface. Thus you could pass in a paper towel, cloth towel, or even your shirt as long as they all implement the Wipe Liquid Interface.

Let’s look at encapsulation and its fraternal twin, information-hiding. Trying to define these separately gets confusing, and in fact they are often used synonymously.  We group things that logically go together in a construct that separates the internal details from its external interface. Grouping these things together is essentially encapsulating them, but hiding the details completes true object-oriented encapsulation. So why do we do this?  Oh you know the answer… to help separate concerns! If I have a User object and it contains a Password, no one outside of the User object need concern themselves with the makeup of that password. Is it a string? Is it numerical? Is it encrypted? Back in OO land we encapsulate things inside classes and we hide everything about that thing so no one has to be burdened with the knowledge, no one has to be concerned with that information except the class. Like always the benefits are that the code will be easier to think, work, understand and communicate about. The user object does not provide access to its internal structure, but instead provides methods so that if calling code has a question, the user can answer it. For example, we may decide that the purpose of a User object is to validate that a person can gain access to the system. The user object might expose a method called CanUserGainAccess that takes in a string password. The user object compares that to the password string it has and then checks to make sure the user is not disabled. If all is cool it returns true. We decide later that passwords should be encrypted. So we go to the user class and change the logic for determining access to encrypt the given password before it is compared. No code outside the user class has to change. We are sure about this because the password is hidden behind the class.

Some mistakenly think they are providing data encapsulation by not exposing data behind a class directly but rather indirectly via an accessor/getter method. So instead of a class having a public member variable like Password, they write a getter method that returns a reference to the member variable. However, this buys us nothing. For example, when a password that was an integer changes to a string any code using it will now bomb. God forbid the Password property was public, it might take quite a while to find all the places where it will bomb. Also, where is all the logic that makes decisions based on user information? We can’t say in the User object, because with its data exposed anyone might have been getting the data and making some decision based on it.

In the end, all I hope to get across by the mental “The Separation of Concerns” sign in my head is that any design choice is made better by applying this credo. You can apply this in any language, object-oriented or not. However, the beauty of an object oriented-language is that it is directly geared towards helping you do this.

References: Tell, Don’t Ask

Procedural code gets information then makes decisions. Object-oriented code tells objects to do things.  — Alec Sharp

Is Object-Oriented Analysis & Design appropriate for the common business application?

Why Object-Oriented Design

The number one reason to employ an OO design when building software is to reduce complexity. The point is that often OO is not used because people think it adds too much complexity. I like the plain English translation from business knowledge to a business object design. When my business expert and I are trying to figure out why interest payments paid on a structured note is sometimes off, and that she noticed it on the reports and on the website, I can translate what we are talking about straight to business objects. If the expert says a structured note pays interest then I can go to the Structured Note business object and find the logic that deals with figuring out the interest payment. As the two of us talk about the business, the language we use reflects real life and the software with minimal translation. The book Domain-Driven Design by Eric Evans is all about this advantage of OO design and he heavily stresses the need for a ubiquitous language used whenever talking or writing about the business.

Furthermore, this type of design organizes things well and lends itself to simple diagramming and other modeling techniques to make it easier to “white board” things with other engineers and business experts. This is simply because the system is broken down in to smaller, self-contained parts. Parts that can be analyzed, tested and understood independent of the other parts. This makes the parts like smooth painted wooden blocks that are a joy to build with compared to wooden chunks cut from a tree. When maintaining or extending an OO application we can often find our way through the code thanks to logical relationships between things (like a User Account and Password) because the real-life relationships are also modeled. Anti-OO procedural-coding advocates often argue that everything achieved in OO can be achieved in procedure code. However, in this case they tend to just focus on cohesion, coupling, and data hiding. These are great benefits of a good design, but OO languages have many built-in constructs that facilitate these benefits as opposed to relying on coders to do them correctly. A separation of concerns is our greatest ally in dealing with complex code, why not use a language and design method geared toward this exact thing!

Creating abstractions of concepts using classes allows us a clean way to hide implementation and divide and conquer complex things while maintaining a simpler programming interface as all the nuances don't need to be thought about at once.

Dividing our information into objects that match the real world forms an organizational framework that at its higher levels is more stable when compared to software organized around data or functions. Granted OO is about putting functions with the data, but an object model, a business object model is first and foremost all about those objects. The data and functions are less stable than the objects.

Tesler's Law of Conservation of Complexity: You cannot reduce the complexity of a given task beyond a certain point. Once you've reached that point, you can only shift the burden around. (Larry Tesler) It is this shifting around coupled with dividing system intelligence that OO developers use to produce simpler programs dealing with complex relationships and logic.

When we adhere to OO design heuristics, or as many as we can, we gain confidence that our system is not fragile and destined to break as we change code. Following rules of encapsulation we are confident that changes affect only small portions of our code. Writing cohesive objects makes the division of complex elements easy to manage as we divide and conquer systems into smaller and more understandable parts

It is true that OO design is not a cure-all for our programming woes. As it is often said, a bad programmer using OO methods can create software that is just as bad as a bad programmer using procedural coding methods. Common pitfalls to the OO developer include inheritance frenzy, ravioli, and Micro-OO.

Inheritance Frenzy

Inheritance Frenzy occurs often when a novice OO developer is fascinated by the powerful inheritance relationship. Before you know it everything IS something else and when I load a Person Object from the database it also loads up all the Human Object data which also loads up all the Mammal Object data, etc, etc. Classes start inheriting functions and properties that don’t quite match the abstraction they represent and methods are overridden left and right. This is not a fault of OO design but a common mistake when modeling a business.

Micro-OO

Micro-OO is a term refers to the introduction of complex patterns to solve “problems.” This is not meant to be a dig at the use of design patterns, but the overuse of “elegant” solutions that encapsulate OO techniques but only add to the complexity of things.  This is a type of over-engineering where creative minds in search of a neat solution get carried away. 

Summary

The short answer to the question, “Why Object Oriented Design?” is simply to reduce complexity. When a business is already complex by nature, it is only beneficial to make the software representing that business use an OO design to help manage that complexity. Testing, debugging and extending applications can be complex, an OO design helps reduce this kind of complexity as well.

What is Object-Oriented Analysis and Design?

Object-Oriented Analysis and Design is the collection of approaches and processes used to develop a software system that has an object as its base structure. The concept of an object in this regard can be thought of like a cell being the base structure of all life. When you focus on the creation of objects that when implemented together in various combinations creates the functionality of your system, then you have an object-oriented system. This is not to be confused with an object-based system which uses objects and classes, but only to the extent that the constructs hold data to be used by the system. In an OO system the objects, more specifically the business objects, contain the brains of the business.

Common Business Application

A common business application is software developed to facilitate the operation of some industry. These applications are complex enough that we often require business experts to work in tandem with us to get the business successfully modeled in software. The common business application is not about Creating, Reading, Updating, and Deleting data from a database. Rather the common business application is about managing a business that figures things out, calculates answers, automates processes and as a result creates things, consumes things, changes things, and removes things.  This is an important point of view that separates a business application from a database-babysitting application which has a different "data-centric focus." This common business application is not a marketing website, or a one-off standalone utility to transfer files across a network. It is not an application that is written in a week. Maintainability and understandability are at a higher premium than the speed at which it can be completed and even operates.  This is not to say a schedule and performance are not important, but rather not as important as maintainability and understandability.

I feel the need to define the common business application because I can expect (based on past experience) that people will counter my points with examples taken from trivial applications that they are writing in their basement for their uncle’s pawn shop. Although this sounds like a funny example, I think there is a lot of equivalent work being done by professional software contractors pumping out code for clients as fast as they can that will be completely rewritten in 2 years.

Examples: Common Business Applications