I am working on a personal web MVC project, whose structure - based on this article - could be described like this:
- The domain model: contains use cases, other services, entities, etc. It is decoupled from the other project components. Not only in regard of its structure, but also of its place in the file system. That is, it resides in a separated directory (so that, in the future, it could serve multiple delivery mechanisms, like console, desktop, etc, if wished).
- The web delivery mechanism: consists of controllers, presenters, view models, templates, etc. It is thought as a plugin to the domain model. It is aware of (e.g. uses) the domain model, but the domain model knows nothing about it.
- The persistence component: is thought as a plugin to the domain model as well, and it resides in a separate location relative to the other components too.
- Any external services/libraries have the same characteristics as the persistence component.
The (wished) working principle is actually a Use Case Driven Design one:
- A controller calls a use case in the domain layer. This "coordinates" the business logic and the persistency (and any other external services), and returns the results back to the delivery mechanism. The presenter receives the result data and presents it to the user (through the other delivery mechanism classes).
- Each controller has only one method, which calls a corresponding use case.
- To each controller corresponds a presenter. So there is a 1:1 relation between them.
Unfortunately, having the above in mind, I am not really sure:
- Should a use case class have multiple responsibilities, so that it can return the data for a whole web page?
- Or, if not: is there something that I am missing, which makes a use case class to actually correctly follow the Single Responsibility Principle?
Thank you.
Aucun commentaire:
Enregistrer un commentaire