Clean Domain-Driven Design in 10 minutes

Source

Key takeaways

• Domain-Driven Design (DDD) works with Clean Architecture (CA)
• Clean DDD in a practical way (microservices)
• Clean DDD on the cloud-native way

I wrote about CA topic last year and today I’m going to write out another part of it. CA is good to make the software architecture more succinctly and manageable, but the boilerplate codes are also huge (if you used to implement it you will get my point — a lot of requests, responses, interactors or use cases, interfaces, and classes need to be created, see my implementation at https://github.com/thangchung/blog-core). Back in the time, when we implement Command Query Responsibility Segregation (CQRS) and Event Sourcing (ES)patterns that will make many people feel unhappy with those of boilerplate codes. That’s a reason I research and write out what I know and learn about make CA more practical and maintainable ways.

For those people aren’t familiar with CA, please see my previous article at https://hackernoon.com/applying-clean-architecture-on-web-application-with-modular-pattern-7b11f1b89011

Let’s start with the whole picture in the application I have worked in a way of CA as following

1. Domain code that doesn’t depend on any framework or libraries. It makes these core components can re-use in the future
2. A bit outer layer of domain code that acts like adaptors, we use it to implement Unit of Work (UOW), Generic Repository (GR), Event Bus, Dependency Injection and a lot of more stuff
3. Partial CA patterns with request and response DTOs and handlers for them. We utilize MediatR and AutoMapper libs for simplifying this kind of work, and another reason that it’s cool 😍 Thank you Jimmy!
4. Partial presenter for Web API

After implemented, it will end up with the structure of code as below

Nothing hyper to talk here, it quite simple and clean, right? Lets diving into the details so that we will understand more about it. I’m going to show you the Cart Service (miniservices pattern actually) with the business like add a new product to a cart, add more product to that cart, get the current cart with products, update that cart, delete product out of the current cart, and final action is to check out the cart.

https://www.gartner.com/webinar/3437517

That’s it. Then we have the use cases like

If you like API first approach, then we should have the OpenAPI as

Let's narrow down to the code because I know that all we are developers so that the code should be easier to understand, right?

Domain components (mainly DDD patterns)

Cart.cs

CartItem.cs

Product.cs

Infrastructure components

Unit of Work, Generic Repository, Event Bus, ClientRequest, Dependency Injection… components are in NetCoreKit — A set of cloud-native tools and utilities for .NET Core — which is developed by myself (https://github.com/cloudnative-netcore/netcorekit).

Request/Response handlers

• Get Cart with Products

• Add Product to a Cart

• Update Product in the Cart

• Delete Product in the Cart

• Checkout

Web API Presenter

Cloud-Native parts

This is the cloud-native apps so that we can package it to a container and host it Kubernetes if we want. The work to do that as below

Dockerfile

Kubernetes manifests

That’s it for today. Hopefully with a ton of code that doesn’t make you dizzy 🙏.

Recap

The world has changed a lot from years recently so that we need to learn and flow with it. In this article, I showed you how can we combine CA with DDD, and host it to the cloud-native platform( Kubernetes in this case). That knowledge is my own, you can think of it in another way or create another stack for your own.

The source code for this article can be found at https://github.com/vietnam-devs/coolstore-microservices

Thanks for reading! If you enjoyed this article, be sure to click 👏 symbol below so others will see it.