Traditional approach
The traditional approach to developing business applications treats the low-level technical domain of programming languages as the only way to formalize a business. This makes PL code the fixed reference point for all other activities, pushing the business domain to the opposite pole of accessibility—no longer directly expressible or approachable. As a result, one is forced to embark on a lengthy and informal journey from the business side to the technical side, often losing sight of the former in service of the latter.
The business domain remains an intangible concept, loosely translated into “software requirements,” where both the process and the requirements are informal and ambiguous. We argue that this very vagueness is the root cause of many problems in software development.
At the same time, attention shifts to the technical side simply because it is easy to grasp: it is already formalized within the IT domain—programming languages, databases, messaging systems, and so on. Beginning software construction by writing message schemas, APIs, and database tables means starting at the wrong end—starting by directly encoding the technical effects.
It is the technical floor that is in the driver’s seat: that is the level of reality within which the business actually operates. There is no formal business-level counterpart to it.
All executable artefacts exist only on the technical floor; the business floor has no direct access to it and only exerts an informal, indirect influence via “requirements” submitted to the technical floor. The actual correspondence between the two floors does not exist in any formalized form—it exists only in people’s heads and is therefore not enforceable.
Traditional problems of software development do not arise from failing to follow a particular methodology—whether best practices, architectural conventions, or design patterns. These methods are merely tools for navigating an unfavorable position.
They already presuppose starting from the wrong place—the technical pole. Over time, these problems compound, until more effort is spent untangling artificially created technical issues than actually working on the business logic itself.