I’ve been studying Domain-Driven Design principles and I’m questioning whether the layered architecture pattern is too rigid for real-world applications.
The standard approach suggests that each layer should only depend on layers beneath it. But this feels like an artificial constraint that doesn’t match how well-designed software actually functions.
Consider UI and business logic interaction. When a user clicks a button, the UI calls the business layer. But when the system needs to notify users of background events, the business layer must communicate back to the UI. Both directions require references and coupling.
Using interfaces and dependency injection, we can make components loosely coupled regardless of which “layer” they belong to. A database abstraction layer is just as independent from domain logic as domain logic is from the database.
Wouldn’t it be more accurate to view software as interconnected modules communicating through contracts, rather than forcing everything into a hierarchical stack? Modern applications often include external APIs, message queues, and cross-cutting concerns that don’t fit neatly into traditional layers.
The observer pattern example reinforces my point. To implement notifications, the business layer needs references to UI components, contradicting the supposed one-way dependency rule.
Am I missing something fundamental about layered architecture, or is this pattern more of a conceptual guideline than a strict rule?
layers r just mental shortcuts that became dogma. i’ve worked on microservices where “layers” span network boundaries - the whole concept breaks down. ur right about bidirectional flow too. most real apps ignore these rules anyway.
You’re right - strict layered architecture feels artificial because it is. I’ve worked on enterprise systems for years, and layers are really about organizing your thoughts, not following rigid rules. Here’s what most people miss: modern layered architecture isn’t about blocking all upward communication. It’s about controlling HOW things communicate. Method calls go down, but events and notifications can bubble up through abstractions. For your UI notification example - don’t let the business layer hold direct references to UI components. Have it publish domain events that the presentation layer subscribes to. You get separation while still allowing bidirectional flow. I’ve watched teams dump layers entirely and end up with spaghetti code. The sweet spot? Treat layers as bounded contexts with clean contracts between them. Think vertical slices talking through horizontal boundaries, not a rigid stack. The constraint makes you think about dependencies and coupling. That’s valuable even when you bend the rules.
Exactly. Traditional layers are a nightmare with modern systems that need real-time updates and cross-cutting concerns.
I gave up fighting this years ago. Instead of cramming everything into fake layers, I automate the entire data flow.
When a user clicks something and you need business logic AND UI updates AND external logging - layers just create obstacles. You get callback hell or event spaghetti trying to keep those boundaries.
Solution? Automated pipelines for the complete workflow. User clicks → automation runs business rules → data processes → systems update together → UI refreshes.
No more “which layer talks to what” headaches. The automation platform handles routing and dependencies based on actual business logic, not textbook hierarchies.
Scales better too. Need new integrations or workflow changes? Update automation rules instead of refactoring layer dependencies across your codebase.
Latenode nails these complex workflows. Connects components and external services without forcing rigid architectural patterns.
Hit the same wall building notification systems at work. Traditional layers fall apart fast when you need bidirectional communication.
The problem isn’t separation of concerns - it’s the rigid hierarchy. Modern apps are more like orchestrated services talking through events and APIs.
I gave up fighting this and automated the whole communication flow. Instead of making UI wait for business layer callbacks, I built event-driven workflows that handle everything automatically.
User action triggers business logic → system fires events → multiple components listen. No more layer violations or dependency injection headaches.
Automation routes messages between components based on actual rules, not artificial layer restrictions. Database updates trigger UI refreshes, API responses update multiple modules - all without breaking anything.
Layers work great for thinking about separation, but they’re terrible for implementation. Event-driven automation actually solves the problem.
I use Latenode for these automated workflows between app components. Connects everything seamlessly without forcing rigid architecture patterns.
You’re mixing up implementation patterns with architectural concepts. Layered architecture isn’t a physical constraint - it’s just logical organization. I’ve debugged tons of systems where devs took the “no upward dependencies” rule way too literally. Layers are really about clear responsibilities and keeping things testable. You’re right about UI-business logic communication, but ditching layers entirely isn’t the answer. Layers can talk both ways using different mechanisms - direct calls down for queries and commands, events or observers for upward notifications. Here’s the thing: patterns like DDD actually work with layered thinking, they don’t replace it. Your domain logic stays in its layer but publishes events that upper layers subscribe to. You keep separation of concerns while getting the flexibility modern apps need. The real payoff comes during maintenance and testing - you can mock entire layers and predict system behavior way easier.
ur spot on! been dealing with older systems too, and the strict layers make things super hard. that “no upward talking” rule just crumbles when real-time stuff comes into play. hexagonal architecture rocks - it’s all about comms thru ports and adapters, no more weird layers!