Categories
Best Practices DDD Patterns Science TDD

Symmetry, Conservation of Energy and Algorithms

In Physics we know the principle of a conserved quantity. A conserved quantity is something that doesn’t change while other variables in the system are modified. For example, the total energy in a closed system can neither disappear nor can it grow over time out of nothing. The amount of energy is conserved.

Some of these conserved quantities have been discovered by physicians centuries ago by observing nature and studying its laws. Energy is one of them, also widely known are the electrical charge, the momentum and the angular momentum.

Mathematics and laws of physics

The mathematical background was discovered by Emmy Noether in 1918: each symmetry in a set of equations (i.e. the laws of physics) reveals a conserved quantity.

What does this mean for us as software engineers? The theorem of Emmy Noether is universally valid, so it can be also applied to business rules/business laws.

A conserved quantity is something that neither can be produced nor can be removed from a system. It is invariant. So in business rules, what does a conserved quantity mean?

Business Rules as “Laws”

If we treat business rules as “laws of the system”:

  • They define what is allowed, forbidden, or invariant in transactions, processes, or data.
  • Just like natural laws, they constrain what can and cannot happen inside the business.

So a “conserved quantity” in business would be an invariant that cannot be created or destroyed inside the system, only transferred or transformed.

Examples of Conserved Quantities in Business

Here are some concrete cases:

  • Money in Accounting:
    • Within double-entry bookkeeping, money isn’t created or destroyed by transactions, it only flows from one account to another.
    • The sum of debits = sum of credits is a conserved invariant.
    • Violating it means the rules are broken.
  • Customer Loyalty Points:
    • Points can move between accounts or be exchanged, but the total issued vs. redeemed must balance.
    • If points just disappear (without being redeemed) or appear (without being issued), the system is inconsistent.
  • Inventory Units:
    • Stock levels follow conservation.
    • Items don’t “vanish” or “appear”, they are either sold, shipped, or produced according to rules.
    • A warehouse system models this conservation explicitly.
  • Information in Workflow Systems:
    • A “case ID” or “contract ID” can change state, but it never ceases to exist arbitrarily.
    • That identifier’s persistence is a conserved aspect.

From Symmetries to Invariants

So far we have identified conserved quantities by looking at what “feels” invariant. But Noether’s theorem gives us a more powerful tool: if you find a symmetry in your business rules, you can derive the conserved quantity from it.

Two practical examples:

Time symmetry → Transaction invariant
A bank transfer must have the same properties regardless of when it is executed: the debit and credit are always equal in size. This time invariance of the booking rule reveals the conserved quantity directly – the total amount of money in the system is preserved. Whenever you find a business rule that holds identically at any point in time, you have found an invariant worth protecting in your data model.

Organizational symmetry → Product identity
A product SKU refers to the same thing in Sales, Logistics, and Finance – regardless of which department is looking at it. This symmetry across organizational boundaries reveals that the SKU is a conserved quantity: it must not be defined differently in one system than in another. In practice, violations of this symmetry are a common source of data inconsistency in enterprise architectures. The moment a product “means something slightly different” in two departments, the invariant is broken – and you have a bug that no unit test will catch.

Why It Matters for Software Engineers

For us, this perspective helps in system design:

  • Identifying invariants: what must never be violated (e.g., balance sheets, transaction logs, legal constraints).
  • Designing checks: enforce invariants through validation, constraints, or event sourcing.
  • Modeling flows: think in terms of transfers and transformations of conserved quantities, not arbitrary changes.
  • Detecting bugs: if a “conserved quantity” seems to change without cause, there’s likely a data integrity issue.

The deeper insight from Noether’s theorem is not just that invariants exist – it’s that they are discoverable. If you look for symmetries in your business rules, you will find the invariants your system must protect. That’s a powerful lens for any architect.


By marcus

Deputy Head of Department Technical Components.
Teamlead, Developer and Architect.

Leave a Reply

Your email address will not be published. Required fields are marked *