Main idea

The two technical divisions of a piece of software do not carry the same business value, and confusing them costs an entire project.

The modules — invoicing, purchasing, access rights — were drawn by developers, but they roughly correspond to areas of the business. That is a partial description, free, validated by years of use: a starting point you would be wrong to reject on the grounds that it comes from the code.

The tables do not. A table is not a business object: many exist only to connect two other tables, keep a technical trace, store login tokens or temporary results. Writing one card per table amounts to copying the technical structure as it stands and describing, on an equal footing, what matters and what means nothing to anyone talking about the product.

The third possible division — folders, worked through in order — bears no relation to business importance and produces a mass of cards with no way of knowing which ones count.

Layer added by "Ontology-Driven Design: what if the ontology became the safety net for AI-generated code?" (2026-10-29). The same gap holds for the other units of the code. A class is not necessarily a business concept, a new package may be nothing more than a technical reorganisation, a function can implement a rule without being a concept. An ontology that follows the code must therefore stay independent of its architecture — hexagonal, Domain-Driven Design or messy code: the model represents the domain, not the technical structure.

Why it matters

It settles the first decision in any description work: where to start. Leaning on the modules costs nothing and gives an order that has already been validated; leaning on the tables means redoing by hand, object by object, the sorting the database does not do.

It holds more broadly: an inherited division should be neither adopted nor rejected wholesale; it is judged on what it cost to produce and on what it encodes of the business.

Nuances and limits

The approximation the modules give is still an approximation: objects exposed externally may be scattered across several modules, and so stay invisible as long as you move forward area by area. That is why working module by module has to be backed up by other ways of listing objects.

And the tables do keep some value, but as a cross-check — they surface stored objects that no description mentions — never as a work plan.

Open questions

• On software whose modules no longer match the business because the organisation has changed, which inherited division takes over?