NDC talk on SOLID in slices not layers video online

The talk I gave at NDC Oslo 2015 is up on SOLID architecture in slices not layers:


In it I talk about flipping this style architecture:

To one that focuses on vertical deliverable features:


About Jimmy Bogard

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.
This entry was posted in Architecture. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Phmager

    Thanks for sharing. Great talk! Especially the file organization structure was very interesting.

  • Marco

    Jimmy, I’m not sure about the authorization being domain-agnostic. Say that I have a CQRS architecture and a set of microservices. By using CQRS we typically end-up with a list of actions we can perform against a given set of services, so I would imagine that it would be a common sense to build user permissions around commands and queries and in this case authorization wouldn’t be domain-agnostic in the case of the commands. If I have a service X which handles commands X1 and X2 which translate into permissions p_X1 and p_X2 for that service, and given that API requests are translated to domain commands, I just can’t understand how come the dependency isn’t there, between the authorization and the domain.

    • jbogard

      You’re right, if you change the context of which I was referring to your approach should change. Everything I talked about is inside a bounded context. So is CQRS though, that’s a pattern inside a service boundary.
      It’s a completely different discussion to talk about compositional patterns for multiple bounded contexts/services.

      • Marco

        I get what you’re saying, yeah it makes sense.

  • Richard

    Fantastic presentation – thank you.

    I was very interested the part where you talk about how you do validation.
    What is your opinion on the annotations applied to model fields that then generate a client-side validation experience?
    We have used the annotation approach that sort of comes with ASP.NET because that saves from having to write the rules twice – server side and client side. Where jQuery validation alone was not enough we have used the Expressive Annotations library (for scenarios where some field Y is required if field X has a certain value).

    I like the look of Fluent (strongly typed and all) but I am not sure how to get the same user experience we have now (e.g. user fixes validation problem and the error message for said field goes away) without writing validation over and over again.

    Also, with forms that might have sub-elements that you add (so perhaps a course enrolment form where the user then adds one or more electives) do you include this as one over all “create” command for the course? Or does a course command handle just the course and then another command handles the electives that are added to a course?
    Finally (and forgive my naivety) but when you say if you have complex business logic you tend to push this down into the “domain models”, what part of an ASP.NET MVC project are you talking about exactly? Are these typically the same classes used by EF itself or higher up?

  • Antony Simonu


    Great presentation as always.

    Given that you don’t use repositories, I was curious how you test your handlers. Do you use in-memory DbContext / DbSets, purely rely on integration tests or some other option?

  • Peter

    I enjoyed your talk Jimmy. Have you ever considered doing an in depth course building an app start to finish with these techniques?

  • miraclespain

    Great talk Jimmy. Im curious how you handle data that is needed in the layout. It could be user specific customizations of layout, a dynamic menu per user or similar.

    Basically a viewmodel for the Layout, a simpler example could be simply the Username to display in a topbar or similar.

    • jbogard

      Child actions for these things work well for me.

  • Ro

    Enjoyed that talk, thanks. Feature folders makes a lot of sense. How do you approach a Feature that is mostly just a report or view which joins data from a couple of tables. A folder for the query and view, leave out any writes/commands?

    • jbogard

      My folders were centered around the controllers, which were logical groups of features. That seemed to scale pretty well for us.

  • Hi Jimmy and thanks for really interesting session. Makes think and act.
    However, one thing still left unclear for me. If I look at queries and commands, and I may write logic in handlers for them, where does domain driven development fits in the big picture? where do I implement my aggregate root? do I need one at all? how would I dispatch domain events? Should handlers be implemented to invoke stuff on domain?
    Or your vision is that consumers of the domain just need to know “catalog of available queries or commands” and then just pass in one of another for getting data out or mutation state of the domain?

    Thanks again!

  • Ivan Zinov

    Can you share the code for this example?

    • jbogard

      Check out my GitHub, the ContosoUniversityCore project!

  • Fakhar Anwar

    Hi Jimmy,
    You are mixing two different ‘aspects’. therefore, i reserve right to disagree with you in your approach to consider “slices” and “layers” as mutually exclusive.

    Just put Features (Which you already show as Domain Specific) inside “Domain Layer” and just consider ” Repository / Infrastructure Layer” also as “Domain Agnostic” Layer then logically you are back inside Layered Approach of DDD.

    Technical Architecture of Layers of DDD are inevitable and they form a means of Aspect-Oriented Programming (Horizontals), whereas Features cover Functional Aspects encompassing DDD Layers. We should live with both in Domain-Driven Design.

    • jbogard

      Yeah we still do have *some* layers in our system. But they’re more like a thin UI layer. And I suppose ORM could be a layer? But it’s not something explicit.

      I don’t know what “repository” or “infrastructure” layers are, though. I don’t have those in my apps. Just a folder for small interfaces, but nothing that stretches across the entire app. And I don’t use repositories, they haven’t shown any value for me.