Architecture and ontology
Why splitting a system into modules is always a choice about how the world is built.
The architecture of a software system looks like a purely technical matter: where to draw module boundaries, what to separate from what, which entities to define. But behind every such decision hides a claim about the world — about which things are separate from one another and which are connected. Architecture is applied ontology.
01A module boundary is a claim
When you decide that «user» and «account» are two separate entities or one, you are not merely structuring code. You are asserting something about how the reality you model is arranged. Can one have several accounts? Does the user cease to exist when an account is deleted? These questions look technical, but they are ontological: about what counts as a separate thing and what counts as its property.
In deciding where to draw a module boundary, you decide which things in the world are separate from one another.
02The model becomes reality
The most important thing happens afterwards. Once fixed in code, the model stops being one of many possible descriptions and becomes the reality in which users live. If the system did not allow for a person to have two citizenships, two names, a nonlinear biography — those possibilities simply will not exist. Not because they are impossible in life, but because they are absent from the schema. Architecture quietly determines what can happen at all.
The categories of the database become the categories of experience. What did not fit the model falls out not only of the system but of the world available to people.
03There is no neutral decomposition
Engineers are taught that good decomposition is «natural»: the right boundaries are supposedly inherent in the domain itself, and one need only discern them. This is a useful illusion, but an illusion. The same domain can be cut in many ways, and each cut highlights something and renders something else invisible. The choice of boundaries is a choice of what matters — and therefore a value judgement disguised as a technical one.
04Why an engineer needs this lens
So as to design more honestly. An engineer who sees only technique in architecture considers their decisions neutral and therefore bears no responsibility for them. An engineer who understands architecture as ontology asks: whose reality am I encoding? Which cases am I making impossible? Who does not fit my schema — and what will happen to them?
This is the point where my engineering and my research converge most tightly. To split a system into modules is to make a choice about the world. Better to make it with open eyes.