Starter pack for the perfect project
I work as a backend developer myself, but I'm actively moving towards full stack. And I still don't fully understand which practices are worth applying, and where they may be superfluous. I would like to know how to distinguish between situations when certain approaches are really needed and when it is better to avoid them.
In my work, I use quite classical approaches, such as Clean Architecture, where the project is divided into several layers.
I also use Repository and Unit of Work patterns to work with data.
Additionally, I implement caching, logging and write a global error handler in the form of middleware. Sometimes I use FluentValidation to validate data.
However, I have a question: is this set of practices enough to create a high-quality project, or are there other approaches and techniques that would be worth considering and adding to the arsenal?
I just want to be clear, for beginners, the type is the most powerful starter pack of technologies that needs to be used, and which is optional, but the type is + in the piggy bank.
6 Replies
Sure it's enough, many a project has been built on that
If you're looking for something to consider, I'd look into VSA architecture instead of CA
$whynotca
CA is not necessarily difficult to understand conceptually, but they're difficult to build and difficult to maintain. When you build a real project, you will quickly (as often evidenced on this server) run into questions like "Is this an infrastructure object or a domain object?" or "Should I implement this contract in the infrastructure or the application?". Questions that a) take your time to ponder and ultimately answer, and b) distract you from doing your actual work.
It also adds unnecessary abstractions, by forcing you to use layers: both unnecessary layers and unnecessary decoupling between layers. For example, CA would generally argue that you should abstract the database into repositories and services should depend on an interface for the repository. However, modern ORMs like EFC already implement the repository pattern, by abstracting the implementation of a query via LINQ. Furthermore, in most applications, there's only one implementation of
IXxxRepository - so why create the interface abstraction?
Instead, it's generally better to get rid of nearly all interfaces, keeping only ones that truly have more than one implementation; simplifying maintenance because any change to an api only needs to be done in one class instead of both class and interface. Smush all of the code down into a single Web project, or possibly two: Web and Services projects; removing any questions about "which project does this class go into?". Organize your code well in the Web project, with all of the User-related services/controllers/models/etc under /Features/Users/Xxx; all of the Order-related services/controllers/models/etc under /Features/Orders/Xxx; etc. Then it will be easy to find and maintain all of the code related to such and such feature. Any Infrastructure code (like emails, behaviors, startup code, etc.) can go under /Infrastructure/Xxx, and any non-infrastructure code that's not related to a feature can go under /Features/Shared.'ere
Do we have a $vsa tag...?
Yes we do
You might want to ditch repositories and UoW as well, since EF already provides both:
DbContext being the UoW and DbSets being the repositories
Caching, logging, exception-handling middleware, Fluent Validations, all of that is the good stuff
So keep it upThank you so much, for answering my question !
adn than to bot for links
ahah