Saturday, December 21, 2013

The Four Architectures that will inspire your programming

This is the Big 4. The architectures, that may help your work. They may influence the way you think about programming.

1. The Hexagonal Architecture

(also known as the Ports and Adapters)

Originally described by Alistair Cockburn in
Enhanced and popularised by Steve Freeman and Nat Pryce, thanks to their book:

2. Clean Architecture

Originally described by Ivar Jacobson, but popularised by Uncle Bob:


DDD: Domain-Driven Design
CQRS: Command Query Responsibility Segregation

Two separate concepts, but together create quite a unique architecture.
DDD is originally invented by Eric Evans. CQRS is often popularised by the work of Greg Young.

4. DCI

DCI: Data Context Interaction

James Coplien, Trygve Reenskaug
Desribed in James' book: and here:

What I think about them

I don't treat them as competitors. Learning the concepts behind them (still in progress) inspired me to bring some new ideas to our projects. Usually, they're not all or nothing.

The most mind-blowing architecture is definitely DCI. This is the future of programming. The vision of objects being different things in different contexts, while still keeping its identity is fantastic. Unfortunately, DCI is also the hardest one to use in day-to-day practice. Some of the concepts required (objects with roles) are hard to achieve in most popular languages.

The most practical architecture is possibly DDD/CQRS. There is a lot of example projects in many different languages. I love the pragmatic approach of splitting the system into Commands and Queries. At first, I couldn't get the point, but after more reading I see the beauty of it. I sometimes laugh that DDD could stand for (data) Duplication-Driven Design. It opened my eyes to the idea, that we can have multiple subsystems, each with its own storage. Some data will be duplicated this way, but it's often not a problem. The data is eventually consistent.

Another nice thing about DDD is the idea of Bounded Contexts. It's a terrible name, but a really useful concept of a module that encapsulates one little world of your project. Usually, you have one root object in each Bounded Context, which is called Aggregate. The same 'object' can exist in different BC, but will have a different name. Its identity will be kept via a unique id.

CQRS brings the concept of Commands being the most complex parts of your app, while Queries are usually very simple and don't require many layers.

What I like about the Clean Architecture is its focus on clear dependencies and on boundaries. Boundaries should be kept outside of your application. The communication between boundaries should happen via Data Transfer Objects. In the middle there's the Interactor, which represent a UseCase.

Last, but not least, we've got the Hexagonal Architecture. This is what inspired us mostly to create the JavaScript non-framework called It's so easy to extract GuiAdapter and StorageAdapter, leaving the middle hex boundary-unaware.

HexagonalJS is a result of inspiration from all of the above architectures. We took the UseCase/Context part from the DCI architecture with a little bit of the Clean Architecture. The idea of adapters is taken from the Hexagonal Architecture. The middle hex is often implemented using the building blocks taken from DDD. Our unique addition to this setup is a little bit of Aspect Oriented Programming.

Often, when I'm in doubt how to approach a new project, I'm trying to stand far from the Upfront Design. However, it doesn't hurt if I imagine the project in each of the architectures. This gives me new ideas about the domain I'm implementing.

If you liked this blog post, you will enjoy following me on Twitter.


Brian Knapp said...

On the Clean Architecture side, I think you would be interested in Obvious Architecture. It is a working version of Uncle Bob's Clean Architecture that also cribs a lot from hexagonal architecture on the data side.

It's implemented in Ruby, but it can trivially be done in just about any OO language.

Andrzej Krzywda said...

Hey Brian,

Obvious is definitely on my list of things to try very soon :) Thanks for reminding about that!

lobrien said...

DCI is quite well-suited to Scala, where Traits play the crucial enabling role. In the CLR world, C# and F# extension methods can similarly be used for DCI.

Szymon Pobiega said...

Thanks for a good and concise summary of various ideas.

Regarding architecture, there are two schools of thought (at least). According to one of them, concepts you named are architectures because they define how an app is built. On the other hand, if you consider SOA an architecture style, the concepts you mentioned become merely implementation details of services -- a large scale design patterns. I subscribe to this second school of thought.

Second, I don't know that much about clean or DCI but I'd like to comment on DDD/CQRS. First, DDD is not an architecture but more like an approach to design process plus a set of design patterns (Aggregate, Entity). These patterns on their own are not enough and need a higher-level concept such as hexagonal to complete the design. Regarding Aggregates, there can be many of them per BC. The idea of aggregate is that it forms a consistency boundary around a group of objects thus providing decoupling and allows for partitioning.

But overall, good job!

Andrzej Krzywda said...

Szymon, thanks for the clarification!

I'm still in the early phase of learning about DDD/CQRS.

Your blog helped me a bit :)

Andrzej Krzywda said...

William, I like how you called it 'parallel architectures' :)

Anonymous said...

one architecture that I think is well suited to some problem domains and popular with game developers is Data Oriented Programming and entity systems,

additionally, having experience building something large in a functional language is a dramatic shift for some people. It can be interesting to get the perspective from outside OOP paradigms.