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

Packaging & namespacing

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.

The architecture of a system is the high-level view of that system, the big picture, the system design in broad strokes. The architectural decisions are the structural decisions in the system, the ones that affect the whole code base, the ones that define where everything else will be built on top of.

Amongst other things, architecture is responsible for deciding the systems:

  • Components
  • Relationships between components
  • Principles guiding the design and evolution of components and relationships

In other words, these are the design decisions that are more difficult to change as the system evolves, it’s the foundations that give support to feature development.

Continue reading “Packaging & namespacing”

Lean and Agile in Software Development

As this post is quite long, you can get it in PDF here.

Some time ago, at the company where I am currently working, I suggested that we could create some posters about Lean and Agile so that people would keep it in the back of their heads on their day to day work. I also made myself available to explain, to the IT department, what Lean and Agile are all about, but because of lack of time, that explanation ended up never happening.

Lately, I’ve found that there are some people around me that have the desire and need to know a bit more about Lean and Agile, about what they stand for, how their practices should impact our day to day work, and what’s there to gain from it. So I decided to write this post in an attempt to cover that.

I’ve talked about Lean and Agile before, in a post titled What is Lean and Agile about Software Architecture but it had a very restricted spectrum. In this post, however, I want to take it a bit further.

Continue reading “Lean and Agile in Software Development”