BT

New Early adopter or innovator? InfoQ has been working on some new features for you. Learn more

Domain-Driven Design with Onion Architecture

| by Jan Stenberg Follow 6 Followers on Oct 30, 2014. Estimated reading time: 2 minutes |

Domain-Driven Design (DDD) together with Onion Architecture is a combination that Wade Waldron in a presentation states has increased his code quality dramatically since he started using it a few years back. DDD was a kick-off for Wade, a senior software developer at BoldRadius, but it wasn’t until he also learnt Onion architecture that he suddenly found his code more readable and understandable, and far easier to maintain.

Onion architecture is sometimes called ports and adapters or Hexagonal architecture, but Wade believes these are a superset of the Onion architecture.

Onion Architecture Core is the building blocks not specific to any domain or technology, containing generic building blocks like lists, case classes and actors. It will never include technological concepts, e.g. REST or databases.

Domain is where all business logic resides with classes and methods named using the ubiquitous language for the domain. By controlling the domain through the API and putting all business logic into the domain the application becomes portable, all technical bits can be extracted without losing any business logic.

API acts as the entry point to the domain, using terms and objects from the domain. Wade notes that the API should only expose immutable objects to prevent developers from using the exposed objects to gain access to the underlying domain, thus manipulating the domain. The API is were Wade often will starting writing his code, a method as a skeleton with a high level functional test around it, thereafter adding logic to make the tests pass thus driving the implementation of the domain.

Infrastructure is the outermost layer containing adapters for various technologies such as databases, user interface and external services. It has access all the inner layers but most operations should go through the API, one exception being domain interfaces with infrastructure implementations.

An important concept is dependencies, an outer layer can see an inner layer but an inner layer has no knowledge of any outer layer.

One way of verifying a design is to test different scenarios, e.g. what happens if a new database or user interface technology is asked for. By carefully following DDD and the Onion architecture principles Wade thinks it will be possible to accommodate these kinds of changes.

Alistair Cockburn presented his Hexagonal Architecture 2005 as a solution to problems with th e.g. traditional layering, coupling and entanglement.

Russ Miles did a presentation about his Life Preserver ideas, based on the Hexagonal architecture, last year.

A third variant is Clean Architecture by Robert C. Martin, which he talked about last year.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT