4 ms·
Prudent to remember that Robert Martin is a consultant and it's lucrative to sell enterprises a story where their domain logic is a billion dollar asset and fol
by develf 9y ago
Prudent to remember that Robert Martin is a consultant and it's lucrative to sell enterprises a story where their domain logic is a billion dollar asset and following his very particular design pattern will enable them to seamlessly evolve this asset with new technology.
Here's where the story breaks:
- Most app's domain objects and rules are small. You could describe them on a few sheets of notebook paper. The technology implementation (e.g. database or http logic) is a much larger portion of the codebase.
- In most teams, especially startups, the domain rapidly evolves. The technology stacks (databases, SQL, etc) are quite stable and have already been heavily abstracted for reuse over the years. Using these proven technologies and excellent existing interfaces is how you go fast.
- Technology choice isn't just about code interface. Each comes with its own assumptions of system behavior and theory of operation. Plugging a different implementation into your storage adapter interface is the least piece of work you need to think about unless it's nearly a 1:1 swap like postgres -> mysql.
So following a strict clean architecture approach will probably pour concrete around something changing all the time and create friction and extra work in using excellent available technologies.
Instead I'd rather follow pragmatic design guidelines:
- The concept of each component should be clear
- Sensible responsibilities for each component
- Abstractions should serve the composability of your existing design; introduce adapter layers if you truly have more than one implementation
- Keep it simple; optimize for reading the code end-to-end and easier refactoring
These aren't inconsistent with Clean Architecture but probably more productive than adding religious rules.
- dfox 9y agoThe design pattern in question is not that much special in the global sense. It is special in the J2EE/.NET/Enterprise world because it should allow you to automatically generate most of the UI in same way what eg. Flask-Admin does while also taking all the bussiness rules into account. One of the things I'd like to do is implement subset of Apache Isis (which is implementation of essentially this pattern for J2EE) in Python on top of Flask.
- develf 9y agoAutomatically generating a UI from a domain may please a programmer but isn't likely to please a user. That's how you get UIs like the one Salesforce has. That could be the right choice in some situations -- it certainly worked out well for Salesforce and allowing extensibility in their model. However if you want to build an app with consumer usability you'll be putting a lot of unique development effort into your view layer.
- dfox 9y agoReasonable UX for consumer facing application is something completely different from what you want for the back office. And these architectures target applications where the back office part is majority of the UI.
- arwhatever 9y agoThe domain does indeed rapidly evolve, but the technology stacks that you list ("databases, SQL, etc.") are the areas where the least reversible decisions tend to get baked in, so it seems like it would be wise to keep the rapidly evolving domain evolution separate from those areas.
- develf 9y agoYes, you are right. I didn't mean to advocate mixing high level and low level logic, different kinds of concerns together in one component. I just take issue with the Clean Architecture bullseye diagram and its preoccupation with layering, classifying those layers, and strict rules about who can refer to who without creating some additional abstraction to pretend the thing you are talking to isn't the thing you are talking to.
- Chyzwar 9y ago> Most app's domain objects and rules are small. You could describe them on a few sheets of notebook paper. The technology implementation (e.g. database or http logic) is a much larger portion of the codebase. That not true. Poorly understood business logic is where most of your code is. Once you create and depend on business object it is really difficult to change. Because you cannot change you end with writing more code... Your code will largely reflect organisation and process. Only way to have "Clean Architecture" is when business owners are fully committed to project and willing to adapt/change organisation. But because it is easier to change code than people, we end up with multi million LOC projects in COBOL. What this blog post is for enterprise managers that believe in bullshit graphs and layers. Technology is important because it will guide you towards solution. People selling ideas about "You can swap out Oracle or SQL Server, for Mongo" to my corporate masters should be hanged. Next year I will have a project to change database: CP to AP thanks to people like author.