Onion Architecture: Part 4 - After Four Years

 In 2008, I coined a new pattern name called Onion Architecture.  You can read the previous parts here: part 1, part 2, part 3.  Over these four years, I’ve spoken about this pattern at user groups, conferences, and it’s even published in one of the chapters of ASP.NET MVC in Action from Manning.

I’ve been overwhelmed by the traction this pattern name has enjoyed.  Folks from all over the country have written about and have talked about the pattern.  Some of the ones I’ve noticed are here (please comment with more – I welcome it).


Back in 2008, I defined four tenets of Onion Architecture:

  • The application is built around an independent object model
  • Inner layers define interfaces.  Outer layers implement interfaces
  • Direction of coupling is toward the center
  • All application core code can be compiled and run separate from infrastructure


Although there has been significant adoption of this pattern, I have received countless questions about how to implement it in various environments.  I mostly get asked about how it relates to domain-driven design.  First, onion architecture works well with and without DDD patterns.  It works well with CQRS, forms over data, and DDD.  It is merely an architectural pattern where the core object model is represented in a way that does not accept dependencies on less stable code.

CodeCampServer was an original sample of onion architecture, but it also grew as a sample of how to do ASP.NET MVC in various ways, how to use Portable Areas, and how to use MvcContrib features like input builders.  If you are just looking for onion architecture, it has too much going on.  I have pushed a much simpler solution that represents onion architecture concepts.  I have intentionally not included a UI input form or an IoC container, which most people associate with onion architecture.  Onion architecture works just fine without the likes of StructureMap or Castle Windsor.  Please check out the code here and let me know if this presents a simple approach – that is the goal.

When there is enough interest, I will continue this series with more parts.  CQRS definitely deserves some addressing within this architecture, and so do object models that support task-based UIs.

Get the code here at my BitBucket repository.


The Onion Architecture : part 1 : Jeffrey Palermo (.com) Posted on 8.19.2013 at 8:20 AM

Pingback from The Onion Architecture : part 1 : Jeffrey Palermo (.com)

The Onion Architecture : part 2 : Jeffrey Palermo (.com) Posted on 8.19.2013 at 8:20 AM

Pingback from The Onion Architecture : part 2 : Jeffrey Palermo (.com)

The Onion Architecture : part 3 : Jeffrey Palermo (.com) Posted on 8.19.2013 at 8:20 AM

Pingback from The Onion Architecture : part 3 : Jeffrey Palermo (.com)

Interesting Finds: August 20, 2013 Posted on 8.20.2013 at 5:01 AM

Interesting Finds: August 20, 2013

The Morning Brew - Chris Alcock » The Morning Brew #1425 Posted on 8.21.2013 at 2:42 AM

Pingback from The Morning Brew - Chris Alcock » The Morning Brew #1425


Liang Wu said on 8.19.2013 at 4:36 PM

Thanks, Jeffrey! This architecture makes a lot of sense. You explained it very well. Please check this as well:


Daniel Marbach said on 8.21.2013 at 6:11 AM

Hy jeffrey

The onion architecture combined with a feature oriented namespace structure can be extremely powerful. More on feature orientation see here:



George John said on 8.21.2013 at 4:54 PM

I must confess that I have really enjoyed implementing the Onion Architecture in my current project. It took a bit to get the team on the same page but that is primarily because coming from an n-tier world DDD is a little daunting at first. Once they got a hang of it it was smooth sailing.

Richard said on 8.23.2013 at 3:25 AM

Where would you put helper classes? Say I have a helper method that takes two doubles and returns a LatLng instance.

Johan Sydseter said on 9.03.2013 at 7:18 AM

Thank you for an excelent articel.

I have searched much of the web and read one book and a dozen articals about hexagonal arcitecure and your examples is the one that bring the most clearity into how the infrastructure and application service layer uses the domain layer without beeing coupled to it.

I still have problems with understanding how to decouple the presentation layer from the application service layer though, I imagine that the application service layers have to implement interfaces from the presentation layers much like in the ports and adapter pattern to be able to decouple presentation from application services.

Am I on track here?

I haven't looked at your code example yet, but I would be greatful if you could explain how it is possible to seperate a framework based on mvc from the application services.

wil.pannell said on 9.05.2013 at 6:07 PM

(cross-posted @ http://alistair.cockburn.us/Hexagonal+architecture)

The one question that escapes me about ports-and-adapters — other renditions are the “onion architecture,” and Bob Martin’s “Clean Architecture,” which I have also been studying — is the primary port for a rich javascript/html5 front-end. I’m interested in your thinking.

If such a front-end exists, then necessarily much UI logic resides on it. E.g., a keyboard interface — like the IPad virtual keyboard — encapsulates much logic that’s not really relevant to the application, as such.

So is the primary port strictly entail the request/response payloads transmitted to the server via http? Or via a rest API?