Source Key takeaways (DDD) works with (CA) Domain-Driven Design Clean Architecture 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 ). Back in the time, when we implement ( ) and (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. https://github.com/thangchung/blog-core Command Query Responsibility Segregation CQRS Event Sourcing 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 Domain code that doesn’t depend on any framework or libraries. It makes these core components can re-use in the future 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 Partial CA patterns with request and response DTOs and handlers for them. We utilize and libs for simplifying this kind of work, and another reason that it’s cool 😍 Thank you ! MediatR AutoMapper Jimmy 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 ( 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. miniservices 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.
