I’ve been studying Domain-Driven Design by Eric Evans and I’m questioning whether the layered architecture approach is too rigid. The book describes layers as:
“Partition a complex program into layers. Develop a design within each layer that is cohesive and that depends only on the layers below.”
This one-way dependency rule bothers me. When Evans talks about dependencies, he means interfaces rather than concrete classes. But if a UI layer communicates with a business layer through interfaces, aren’t they equally dependent on each other?
For example, when a user clicks a button, the UI needs the business layer. But when the application needs to show notifications, the business layer needs the UI through observers or callbacks. Both directions require references.
Wouldn’t it be more accurate to view software as interconnected modules that communicate through contracts? Each module can be swapped independently regardless of which “layer” it sits in.
The database example illustrates this well. The domain layer uses DAOs to access data, while the database triggers domain events through stored procedures. Neither truly depends on the other more than vice versa.
Instead of linear layers, shouldn’t we think of software as a network of loosely coupled services? This includes external APIs, utility libraries, and domain services branching in multiple directions.
The layered model feels like it forces natural software interactions into an artificial hierarchy. What am I missing about this architectural pattern?
honestly think you’re overthinking this a bit. layers work great for most projects ive worked on, but yeah they can feel forced sometimes. the trick is not being too strict about it - if you need bidirectional communication just use events or callbacks like you mentioned. its more about keeping things organized than following rules religiously. hybrid approaches work fine too.
The tension you’re experiencing is completely valid and something I wrestled with early in my career. After working with both strict layered architectures and more flexible approaches, I’ve come to see layers as organizational guidelines rather than absolute rules. The key insight is that layers aren’t about eliminating dependencies but managing their direction and nature. When your business layer needs to notify the UI, it shouldn’t know about specific UI implementations. Instead, it publishes events or uses abstractions that the UI subscribes to. This maintains the dependency flow while allowing bidirectional communication. I’ve found that treating layers as boundaries for concerns rather than rigid hierarchies works better in practice. Your instinct about interconnected modules is spot on, but some structure prevents the codebase from becoming a tangled mess. The layered approach becomes problematic when applied dogmatically, but as a starting point for organizing complexity, it provides valuable guidance for teams to reason about system structure.
You’re touching on something that took me years to fully grasp. Layers aren’t really about physical separation but about logical boundaries and responsibility isolation. The confusion often stems from conflating architectural layers with deployment or runtime dependencies. In my experience building enterprise applications, the layered approach shines when you understand it as a way to manage complexity rather than enforce rigid communication patterns. The business layer doesn’t actually need to know about UI specifics when it triggers notifications - it publishes domain events that any interested party can consume. This creates a publish-subscribe relationship that maintains the layered principle while enabling flexible communication. Your network analogy is partially correct, but without some organizing principle, systems tend to devolve into spaghetti code where everything talks to everything else. The layered architecture provides a mental model that helps teams understand where functionality belongs and how components should interact. It’s less about artificial hierarchy and more about establishing clear contracts between different areas of concern.