DDD, Hexagonal, Onion, Clean, CQRS, … How I put it all together

This post is part of The Software Architecture Chronicles, a series of posts about Software Architecture. In them, I write about what I’ve learned on Software Architecture, how I think of it, and how I use that knowledge. The contents of this post might make more sense if you read the previous posts in this series.

After graduating from University I followed a career as a high school teacher until a few years ago I decided to drop it and become a full-time software developer.

From then on, I have always felt like I need to recover the “lost” time and learn as much as possible, as fast as possible. So I have become a bit of an addict in experimenting, reading and writing, with a special focus on software design and architecture. That’s why I write these posts, to help me learn.

In my last posts, I’ve been writing about many of the concepts and principles that I’ve learned and a bit about how I reason about them. But I see these as just pieces of big a puzzle.

Today’s post is about how I fit all of these pieces together and, as it seems I should give it a name, I call it Explicit Architecture. Furthermore, these concepts have all “passed their battle trials” and are used in production code on highly demanding platforms. One is a SaaS e-com platform with thousands of web-shops worldwide, another one is a marketplace, live in 2 countries with a message bus that handles over 20 million messages per month.

Continue reading “DDD, Hexagonal, Onion, Clean, CQRS, … How I put it all together”

Advertisements

MVC and its alternatives

This post is part of The Software Architecture Chronicles, a series of posts about Software Architecture. In them, I write about what I’ve learned on Software Architecture, how I think of it, and how I use that knowledge. The contents of this post might make more sense if you read the previous posts in this series.

Creating maintainable applications has always been the real long-term challenge of building applications.

Not long ago, I worked for a company whose core business application was a SaaS platform, used by a few thousands of client companies. That crucial application was three years old and had code files with HTML, CSS, business logic and SQL mixed up. Of course, two years after being released, the company decided to rebuild it from scratch. Although these situations still happen, today many of us know these practices are wrong and know how to avoid them.

However, back in the 1970s, mixing responsibilities was the common practice and people were still trying to discover how to do it better. As application complexity grew, making changes to the UI would inevitably imply changes to the business logic as well, increasing the complexity of the changes, the time spent to do those changes and the likelihood of bugs (because there would be more code changed).

MCV came into play to solve those problems, by promoting “separation of concerns” between front-end and back-end.

Continue reading “MVC and its alternatives”

Microservices architecture: What the gurus say about it

About a year ago I was very interested in learning as much as possible about the subject and gathered as much information as I could about it. I watched several conference talks and I read several articles from very knowledgeable and experienced people, like Martin Fowler, Fred George, Adrian Cockcroft, or Chris Richardson, in order to learn as much as possible about microservices, and this post is the result of that.

This post talks about:

Continue reading “Microservices architecture: What the gurus say about it”

PPPDDD.3 – Focusing on the Core Domain

An application is made of several components and sub-components, all of which are essential to the functioning of the application. However, there are components more important than others. Continue reading “PPPDDD.3 – Focusing on the Core Domain”

PPPDDD.2 – Distilling the Problem Domain

Distilling the problem domain is about understanding the problem and its domain  in order to uncover what is relevant and create a model that reflects the domain and solves the problem at hand. In DDD, the activity of doing this is called in Knowledge Crunching. Continue reading “PPPDDD.2 – Distilling the Problem Domain”

PPPDDD.1 – What is Domain Driven Design?

Building software that works is not difficult.

What is indeed difficult is to build software that lasts for many years, that keeps working despite the changes needed by the business, needed by the users, needed by new technologies. Building software that is permanently ready for change, and permanently and accurately reflects the business… thats the tricky part. Continue reading “PPPDDD.1 – What is Domain Driven Design?”