What is separation of concerns?

You ask a developer to change one field on an invoice screen, and somehow three unrelated reports break. Or your team wants to add a new discount rule, but nobody can find where the pricing logic even lives — it's scattered across a dozen scripts, layouts, and spreadsheet macros built over the years. This is usually not a sign of bad developers; it's a sign of missing separation of concerns.

This article explains what separation of concerns actually means in practice, why it matters for the total cost of owning your business software, and how to recognize whether your own system has it — or badly needs it.

What does "separation of concerns" actually mean?

Separation of concerns is a design principle that says: each part of your software should have one job, and that job should live in one place.

In practical terms, that means keeping distinct:

• Data — what is stored (customers, orders, invoices, stock levels)
• Business logic — the rules that govern that data (how a discount is calculated, when an order is allowed to ship, what happens when stock hits zero)
• Presentation — how it's shown to the user (a screen, a PDF, a mobile view, a report)
• Integration — how the system talks to other systems (your webshop, your accounting package, a carrier's shipping API)

When these are properly separated, changing one doesn't force you to touch the others. When they're tangled together, even a small change can ripple through the entire system in ways nobody predicted.

Why does this matter if you're not a developer?

Because it directly affects how fast and how safely your software can change — and your business changes constantly: new pricing rules, a new sales channel, a new government reporting requirement, a merger that suddenly needs two systems to talk to each other.

Here's the concrete version of the problem, not the abstract one:

A distribution company built its discount logic directly inside the button that prints an invoice. It worked fine for years. Then sales asked for a new customer-tier discount. The developer had to hunt through the invoice layout's script, find the discount calculation buried inside a button action, copy that same logic into two other places where discounts were also calculated slightly differently, and hope all three stayed in sync going forward. One got missed. Three months later, a customer was invoiced with the wrong discount, and nobody could explain why — because the same rule existed in three places with three slightly different versions.

If the discount logic had lived in one place — a single calculation used everywhere it was needed — that fix would have taken ten minutes instead of a week of digging, and it couldn't have gone out of sync.

What does it look like when separation of concerns is missing?

You don't need to read code to spot the warning signs. Look for:

• The same business rule exists in more than one place. A shipping cost formula that's calculated in the order screen, again in the invoice, and again in a report — with no shared source.
• A UI change breaks something unrelated. You move a field on a layout and a script that referenced its position stops working.
• Nobody wants to touch "that old script." It's grown so tangled with unrelated responsibilities that even experienced developers are afraid to change it.
• Every new feature takes longer than the last one, even though your team hasn't gotten less skilled — the system has just gotten more entangled.
• Integrations are hardcoded into screens. The call to your accounting API sits inside a button on an order form, instead of behind a dedicated, reusable connector.

If two or more of these sound familiar, separation of concerns is likely already costing you time and money — even if nobody has named it that.

How do you apply separation of concerns in a real system?

You don't need to rebuild everything overnight. In practice, teams apply it incrementally:

1. Identify the repeated rule. Find business logic that's duplicated across screens, reports, or scripts (a discount, a tax calculation, an approval rule).
2. Give it one home. Move that logic into a single script, function, or module that everything else calls — rather than letting each place calculate it independently.
3. Keep the interface thin. A button, a layout, or a report should call the logic and display the result — it shouldn't contain the logic itself.
4. Isolate integrations behind a clear boundary. Talking to an external API (accounting, e-commerce, a shipping carrier) should happen through one connector layer, not scattered API calls inside individual screens. That way, if the external API changes its format, you fix it in one place.
5. Document the boundary, not just the code. Even a short note — "all discount logic lives in the Pricing module" — helps the next developer (or the next hire) know where to look and where not to add a shortcut.

Does this only apply to custom-built software?

No — it applies just as much to platforms like FileMaker, where it's tempting to build fast by putting logic directly on buttons and layouts because the platform makes that so easy. That speed is exactly why FileMaker systems can drift into tangled logic over the years: it's rapid to add a quick calculation to a button, and rapid ten times over, until the button does five unrelated things.

Modern tooling has actually made good separation easier to achieve, not harder. Tools like Klai, which bring AI capabilities into FileMaker, work best when your business logic is already isolated and well-defined — an AI assistant can reliably answer "what's our return policy calculation?" only if that policy lives in one clear place rather than being buried inside a dozen scripts. Similarly, presentation frameworks like FmBetterForms are built around the idea of separating how something looks from how it behaves, so a designer can adjust layout without a developer needing to touch business rules, and vice versa.

What's the payoff of doing this well?

• Faster changes. A pricing update touches one module, not five screens.
• Safer changes. Fixing a bug in the presentation layer can't accidentally break the underlying business rule.
• Easier onboarding. New developers can learn one layer at a time instead of untangling everything at once.
• Better integrations. Connecting a new system (a webshop, a carrier, an accounting package) is a matter of calling your existing logic layer, not rewriting rules a second time.
• AI-readiness. Clean, well-separated logic and data are exactly what AI tools need to reliably automate or answer questions about your processes.

Quick checklist: does your system separate concerns well?

• Is any business rule (discount, tax, approval, pricing) defined in more than one place?
• Can you change how something looks on screen without touching the logic behind it?
• Are calls to external systems isolated in one connector layer, or scattered across screens?
• Could a new developer find "where the discount is calculated" in under five minutes?
• Has adding a similar new feature taken noticeably longer than the last one?

FAQ

Is separation of concerns the same as "modular" software? They're closely related. Modularity is often the result of applying separation of concerns — once logic, data, and presentation are cleanly split, the system naturally breaks into modules that can be reused and swapped.

Can an existing, tangled system be fixed, or do I need to start over? Almost always it can be fixed incrementally. You isolate one rule at a time — starting with whichever duplicated logic causes the most support tickets or errors — rather than rewriting the whole system at once.

Does this slow down initial development? Slightly, at first — it takes a bit more discipline to build the "single home" for a rule instead of just pasting the logic where you need it. That small upfront cost is consistently repaid the first time the rule needs to change.

How does this connect to keeping software maintainable long-term? Separation of concerns is one of the foundational techniques behind maintainable systems — our broader guide on how to keep business software maintainable as it grows covers this alongside other practices like documentation, code reviews, and planned refactoring.

If your team is spending more time untangling old logic than building new features, that's usually a sign your system's concerns have blended together over the years — and it's rarely something you notice until it's already expensive. Loggix helps teams map out where business logic, data, and presentation have become tangled in their FileMaker or custom systems, and builds the connectors, modules, or AI tooling — including solutions like Klai or FmBetterForms — needed to pull them apart safely, without a disruptive full rebuild.