NCEFMRFVSxU - .Net Core + EF + MediatR + FluentValidation + Serilog + xUnit

The Heavenly (dev) Kingdom?

To misquote Lord Vader:

Don’t be too proud of this technological terror you’ve constructed. The ability to use .Net Core + EF + MediatR + FluentValidation + Serilog + xUnit is insignificant next to the power of writing everything from scratch.

NCEFMRFVSxU (.Net Core + EF + MediatR + FluentValidation + Serilog + xUnit) is a perfect stack from company's point of view:

• Every developer can change tasks, projects, and even teams quickly
  • Developers don't have to know much about a domain with well-defined tasks
  • Intersection with other parts of the system is minimal (by design)
• Onboarding is quick and easy (for most dev positions)
  • Developers do not need to know (almost) anything about the system before writing a handler
    • Don't cross the streams - follow a few simple MediatR bits of advice like:
    • Dealing with duplication
    • Do not send requests from inside requests
• Chances for (long term) mistakes are low
  • Strict rules & best practices
  • Everything is replaceable
    • Even if you have to replace the entire line from API method to database calls
  • Where are you even going to make a mistake?
    • And if you do, how long will it take to correct it?
  • Most things are isolated
    • Using NCEFMRFVSxU does not necessarily mean modularity, isolation, or good project organization, but with cleanly separated layers both vertically and horizontally, you have many options open
    • Horizontally - Hexagonal Architecture, Clean Architecture
    • Vertical - Vertical Slice
    • By bounded context - Modular Monoliths
    • Even if you decide to reorganize the entire project or ehm split monolith into microservices, you can do that reasonably easily
• Code is uniform
  • No "big" architecture decision
  • Developers are focused only on the task at hand, not on the infrastructure
  • Fewer meetings
    • Developers do not need to ask for permissions; they have everything they need
    • Developers do not need to explain what they have done.
  • System Design and programming are two separate tasks.
  • Test-Driven Development and Writing Tests
    • Even if you can argue that #TDDisDead (DHH, Fowler), with so much uniformity, you don't have a reason not to use it
    • Test model and validations, handlers, and APIs
    • .Net Core has a lot of great options for integration testing and API testing (WebHostBuild)
    • EF has a lot of great testing tools like in-memory provider, SQLite(in-memory), LocalDB (Windows only)
    • Even if you insist on using a "real" SQL Server - you can use Jimmy Bogard's Respawn for setting test databases to a clean state.
  • Stable
    • The entire stack is more than 5+ years old.
    • From reputable companies and people - Jimmy Bogard

Or the Little Slice of (dev) Hell

And for a time, it was good.

The Second Renaissance/Animatrix

Some problems that come to a mind with this stack:

• Everything is in process
  • But you could use Brighter, Mediator with MassTransit
  • Or extend Mediatr with Hangfire
• Relation Databases may not always be the most suitable solution
  • But still, you could replace EF/SQL Server and keep everything else
• Teams - The NCEFMRFVSxU works well, except when it does not. What happens when you have a non-standard screw?
  • A lot of things in NCEFMRFVSxU are predefined by design - this is one of the reasons why this stack gives so much value, but that is also why this stack is dangerous if your team stops thinking about alternatives and new approaches
  • Can your team work together to find solutions to more complex non-standard problems?
• Developers - as individuals, may feel less appreciated and creative

Personal Opinion

I have fought (passionately) for and love each technology on the list - .Net Core, EF, MediatR, FluentValidation, Serilog, xUnit; but after a few months of crunching of NCEFMRFVSxU (with TDD), something inside of you dies. The NCEFMRFVSxU becomes your slice of hell.

But that's probably more a 'me problem.'