When DDD Leads to CRUD

As I progress on the second edition of bestselling Microsoft .NET: Architecting Applications for the Enterprise (NAA4E). I learn more and more about Domain-driven Design (DDD) and, above all, I’m seeing it through the lens of a different perspective. Instead of just blindly applying my understanding of it built on top of tips, tricks and advice collected here and there, I’m truly learning it from the foundation. And guess what? I can now fully answer the following (simple but tricky) question I got on LinkedIn. The question apparently is completely unrelated  to DDD. At a deeper look, though, it’s DDD that is related to nearly every aspect of software architecture; even when it could lead to a CRUD software.

For ASP.NET web applications requiring only CRUD operations(like automating paper forms), do you think using Entity Framework is slower than using DAL, BAL and presentation layer using stored procedures? Is using EF with stored procedure the right solution for this?

There are two distinct parts in DDD. You always need one; and may sometimes happily ignore the other.

1. DDD has an analytical part that sets an approach to express the top level architecture of the business domain in terms of bounded contexts.
2. DDD has a strategic part that relates to the definition of a supporting architecture for the identified bounded contexts. The default supporting architecture is Domain Model. A quickly emerging alternate option–in many ways fully replacing Domain Model–is CQRS.

The real added value of DDD lies in using the analytical part to identify bounded business contexts. This is the part of DDD that relies on the ubiquitous language–the key factor.

Once this has been done, the next problem is identifying the ideal way to tackle (read, implement) each bounded context. In doing so, you can certainly consider the two recommended supporting architectures of DDD. You can even–probably should–consider event sourcing in combination with CQRS.

But, in the end, it’s all about finding the ideal way to meet requirements in a well-understood business context.  So “ideal” should be measured against actual business requirements and NOT against ideal principles of code elegance, cleanliness, future extensibility, readability and the like. If, as in the question, all you need is CRUD and you need it quickly and probably don’t need it after a short amount of time, by all means go with a quick ASP.NET CRUD and stored procedures.

Stay tuned on Facebook for the progress of #NAA4E!