My journey in Clean Architecture and Domain Driven Design

Last year I’ve read several new books about software development. One of them was the book “Clean Architecture: A Craftsman’s Guide to Software Structure and Design” by Robert C. Martin (aka Uncle Bob).

On the other hand I started to use more Domain Driven Design (DDD) practice on my day-job. I read about DDD already several times in the past but never got it really started.

On one hand I like to practice DDD but even more I was hungry to do a Clean Architecture journey and give it a try. What I needed was a peace of software to get started with. Lucky my I had a web application that needed some love anyway. Voila: my journey was ready to start!

In this multipart blog post I write what challenges I faced and what solutions I finally came up with.

Chapters:

• Chapter 1: (this one) Intro and setting the stage
• Chapter 2: Clean Architecture and DDD
• Chapter 3: Controllers
• Chapter 4: Use-Cases & Interactors
• Chapter 5: Entities & Domain Events
• Chapter 6: Presenters & View-Models
• Chapter 7: Drivers & Data Access
• Chapter 8: Conclusion and final words

The web application

The web application I liked to modernize is the one that run on https://tauchbolde.ch. It’s the website of my diving group. Beside some static content and some other diving calculation-gadgets it has two main domains (aka modules): Diving events(Events in short) and Logbook.

The Events domain allows divers to create upcoming diving events/dives and register for them incl. building buddy-teams, place comments, download ICal files, etc. The Logbook domain allows members to write articles about past events with image upload etc. Kind of a simple blog.

The samples in this journey are from the Logbook domain as this simple blog is way easier to understand than then diving stuff.

The website is build using .Net Core 2.2, ASP.Net MVC Core 2.2 and Entity Framework Core 2.2. All the soure-code can be found here on GitHub. The Azure DevOps pipelines are here.

Problems with the old architecture

The old application was build like many common MVC application are: MVC-Controller uses repositories to load/save data and builds the view-model ad-hoc in the controller and triggers the view.

As the logic parts had grown I moved them into what was called domain services and therefore removed data-access from the MVC controllers.

With the time some domain-services started to re-use other domain-services and cross-cutting general purpose services. If became less clear what depends on what and unit-testing these domain services became a challenge on its own.

Read on about Clean Architecture & Domain Driven Design here…