Chapter 1: What Is an Object?
A department within a certain organization was created with a clear commercial purpose and had existed for many years. At the time, its role was obvious and widely understood. People knew its name, its purpose, and its budget. Moreover, the line of business supported by this department was highly profitable and highly respected by the clients it served.
Word of the excellent service spread through business circles, and one day a very large company also agreed to use the department’s services. This was a major success. The contract was signed. Everyone was delighted, and the future looked promising.
The only complication was that the new agreement required a minor reorganization of the department’s responsibilities. It sounded innocuous, and everyone agreed it would not be difficult. The restructuring process began.
It was not an easy process. New employees were hired, many were sent for additional training, and, inevitably, some had to be laid off. During the restructuring, revenue from existing clients declined as attention shifted toward fulfilling the obligations of the new contract. At the same time, revenue from the new major client was lower than expected, largely due to the slower pace of the reorganization.
At some point, it became clear that continuing to preserve a structure whose original purpose had gradually lost its relevance would only deepen the problem. The only viable alternative was to disband the existing department and create two new ones, each focused on a clearly defined area of activity and a clear commercial purpose.
However, time was lost. The restructuring took longer than anticipated, priorities competed, and service levels suffered. Eventually, the new major client terminated its contract, citing an insufficient level of service. The company barely survived.
What had changed was not the past, but the future. Upcoming changes placed new demands on the organization, and under those demands the original purpose of the department began to blur. The structure remained. The name remained. But the meaning no longer fit the direction the business was heading.
Nothing in this story is unusual. There was no incompetence, no bad intent, and no obvious mistake. The department was created for a legitimate reason and served that purpose successfully for years.
The problem did not arise because the department failed. It arose because the world around it changed. New opportunities introduced new demands, and those demands quietly exceeded what the original definition of the department could support.
This is how meaning decays in organizations. Names, structures, and reporting lines persist long after the assumptions that once gave them clarity have stopped being valid. People continue to use familiar words, unaware that they no longer refer to the same thing.
Now, let’s look at the object. In this book, the word object does not come from technology. It simply means something the business treats as a distinct thing — a department, a customer, a contract, or any other unit whose identity is expected to survive change.
An object is not defined by the list of attributes attached to it. It is defined by its purpose and by the conditions under which it is allowed to remain meaningful. When those conditions change, preserving the object at all costs becomes dishonest. In such moments, dissolving an object and creating a new one with a clear purpose is not a failure. It is an act of clarity.
This distinction matters because systems—organizational or technical—tend to preserve structure more easily than meaning. They remember names and shapes, but they do not automatically adapt to changes in purpose.
Understanding what an object truly is—beyond its structure—is the first step toward building systems that can change without losing their integrity.
Table of Content Next: Where Rules Live in Dynamic Systems
Business Process Programming in .Net
© 2004–2026 Laskarzhevsky Software Inc.
Unless otherwise noted, the content of this website is licensed under the
Creative Commons Attribution 4.0 International License (CC BY 4.0).
Code examples are provided under the MIT License.
You are free to share and adapt the material provided that appropriate
credit is given and any modifications are clearly indicated.
The information provided on this website is for educational purposes only.
The author and publisher make no warranties regarding the completeness
or suitability of the information and are not responsible for any damages
resulting from its use.