Upsidedown is a WordPress theme design that brings blog posts rising above inverted header and footer components.

When DDD Leads to CRUD

Written in


F05xx05 - CopyAs 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!


4 responses to “When DDD Leads to CRUD”

  1. Bryan Randal Arendt (@ctrlshiftbryan) Avatar

    For the simplest scenarios I wouldn’t want to have to use stored procedures at all. I usually rely on them for the most complex queries where you may need to use data for the query but not have that data in the result or to leverage advanced database features like Filestream.

    I would recommend EF with Code First for the simplest CRUD. You could then abstract it out to its own DAL but that might not be necessary.

  2. despos Avatar

    Sure, but the point–as I start seeing it–is not much in finding the approach that weds elegance with cleanliness and extensibility. It’s just about splitting the architecture into smaller pieces, relate them together, and implement each the best. The best for you and skills and the best for the problem. But if you know how to do it QUICKLY and it doesn’t have to last for too long, do it. Does that mean using SPs? Fine. I’m not saying that using SPs is OK. But if for a short app you find it OK, why not?

  3. Marco Cecconi (@sklivvz) Avatar

    Don’t use any canned architecture initially. Go with the simplest possible solution — literally.

    Out of 250 projects, 200 projects will never need any architecture (including the CRUD example). They will be underused/failed systems because that’s life.

    Of the remaining 50, about 40 will need some form of architecture, but not the complexity of DDD/CQRS/ES (or any other flavor-of-the-day architecture) — either basic layering or some custom architecture because reasons.

    Of the remaining 10, 8 would probably work with DDD but will fail at implementing DDD because of incompetence — the average competency level of architects and developers is quite shocking.

    The remaining 2 projects will succeed and be touted as proof that DDD works “all the time on real world projects”! 😉

    Moral of the story: not all that is theoretically doable or makes architecture easy is actually needed, appropriate or feasible for the project, and real world projects will not be solved by a priori approach in practically every case.

    (The number above may or may not be totally out of my hat)

  4. Salim Fayad Avatar
    Salim Fayad

    Hi Dino, I really liked your blog and I am waiting your next book Architecting Applications for the Enterprise.

    I wanted to ask you if there is any Rapid Application Development tool that you recommand.

    Thank you

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: