I’ve been going through Eric Evans’ book on Domain-Driven Design. It’s a great read, but I’m not sure about the layers model he talks about. It feels like it’s trying to fit everything into a neat little box.
Evans says we should split complex programs into layers, with each layer only depending on the ones below it. But I’m wondering if this is too simple for real-world software.
Here’s what’s bugging me:
- What does ‘depends’ really mean here? Is it about concrete classes or interfaces?
- If it’s about concrete classes, isn’t that bad for reusability?
- If it’s about interfaces, aren’t the layers equally dependent on each other?
- Shouldn’t we think of our design as a bunch of separate modules that talk to each other through interfaces, rather than strict layers?
- Isn’t the real structure of a program more like a network of interconnected parts, not a straight line of layers?
I’d love to hear what others think about this. Am I missing something, or is the layers model too simplified?
While layered architecture provides a solid foundation, it’s not a one-size-fits-all solution. In my experience working on complex enterprise systems, strict adherence to layers can sometimes lead to unnecessary complexity and reduced flexibility. The real world often demands a more nuanced approach.
I’ve found that a hybrid model, combining aspects of layered architecture with a more modular, service-oriented design, can be more effective. This allows for better separation of concerns while still maintaining the flexibility to adapt to changing requirements.
That said, the layered model still has its place, especially in simpler applications or as a starting point for more complex designs. The key is to understand its limitations and be willing to deviate when necessary. Software architecture, like any design discipline, requires critical thinking and adaptation to specific project needs.
layered arch isn’t perfect but it’s still useful imo. real systems are more complex, but layers help organize things. i’ve seen projects where strict layers caused problems. it’s good to be flexible and use what works best for ur specific situation. don’t get too hung up on theory
I’ve worked on several projects where we started with a layered architecture, and I can say it’s not always the best approach. In one case, we ended up with a tangled mess of dependencies that were hard to maintain.
That being said, layered architecture can be a good starting point, especially for less experienced teams. It provides a clear structure and helps prevent some common design pitfalls.
The key is to be flexible. We’ve had success using a modified layered approach, where we allow some controlled cross-layer communication when it makes sense. This helps avoid over-engineering while still maintaining a generally organized structure.
Ultimately, the best architecture depends on your specific project needs, team skills, and long-term maintenance considerations. Don’t be afraid to adapt and evolve your architecture as you go along.