I’ve been reading about Domain-Driven Design and I’m not sure about the layers concept. It feels a bit forced. The idea is that each layer only depends on the ones below it. But this seems too simple for real software.
Here’s what I’m thinking:
- If a UI class directly uses an app class, that’s bad. It makes the UI hard to reuse.
- If the UI uses interfaces instead, how is it more dependent on the app than the other way around? They’re both separate but connected.
The one-way dependency model looks neat, but is it right? Wouldn’t it be better to say each part of the design is its own thing, talking to others through interfaces? This way, no part really depends on another. You can swap out any piece.
Also, the idea of a straight line from one layer to the next seems fake. Isn’t it more like a web of separate parts working together?
What do you think? Am I missing something about how layers work in software design?
I’ve wrestled with this in my own projects. Layers can feel artificial, but they’ve saved my bacon more than once. When I started treating them as guidelines rather than rigid rules, things clicked.
In one app, I initially ignored layers and ended up with a tangled mess. Refactoring with loose layers helped tremendously. It wasn’t perfect, but it made the codebase way more manageable.
That said, I agree the straight top-down dependency isn’t always realistic. I’ve found success with a more modular approach, where components interact through well-defined interfaces. It gives flexibility while still maintaining some structure.
Ultimately, it’s about finding what works for your specific project. Layers aren’t a silver bullet, but they can be a useful tool in your architectural arsenal. Just don’t be afraid to adapt them as needed.
i get where ur coming from, layers can feel artificial. in reality, systems are more like interconnected webs than neat stacks. but layers help organize complexity, even if its not perfect. interfaces are key for decoupling, regardless of how u structure things. ultimately, use whtever approach helps u reason about ur system best
Software architectural layers aren’t strictly artificial, but they’re certainly a simplification. In practice, systems are rarely as neatly organized as the layered model suggests. That said, layers serve a valuable purpose in managing complexity and promoting separation of concerns.
The key is to view layers as a guideline rather than a rigid rule. They provide a framework for thinking about system organization, but shouldn’t be followed dogmatically. Using interfaces and dependency inversion can indeed help create more flexible, loosely coupled designs.
In my experience, a pragmatic approach works best. Use layers as a starting point, but be willing to deviate when it makes sense for your specific application. The goal is to create maintainable, adaptable software, not to adhere strictly to any particular architectural model.