New answers tagged clean-architecture
4
A good repository should abstract away the underlying database structure. An entity may have its data stored in several different tables, but your domain logic shouldn't care about that. At most, you'd have one repository for each entity in your domain, but you could also just have one repository for each aggregate root. It's up to you to decide what makes ...
1
OK, I think you you have a few misconceptions about the architecture itself and that this is tripping you up, so let me try to sort that out.
So, domain behavior (the business logic of the application) resides within the combined Use Cases + Entities layer. How you split that up internally is up to you, but the guideline is to put the "application ...
2
In clean architecture, a use case consists of three components: a request, a handler and a response.
A request contains user input. Note that the request itself is also input, so it’s not impossible to have an empty request, although typically requests contain at least an id for a resource.
The handler belongs to this specific request and nothing else. The ...
2
While it's of course technically possible to make the Clean Architecture work in any scenario, it actually breaks down quite quickly when the application grows.
It kind-of works in CRUD applications, as you've mentioned, but it's not an accident there are no other examples to be found. Also, if you take a look at Uncle Bob's own project, you'll see it's ...
0
The use-case in a clean architecture is as stable as the other inner circles and more stable than the outer circles such as presenters or UIs:
We do not expect changes in this layer to affect the entities. We also
do not expect this layer to be affected by changes to externalities
such as the database, the UI, or any of the common frameworks.
- ...
Top 50 recent answers are included
