Domain-Driven Design with Onion Architecture
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.
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.