Customer scoring with Camunda synchronous workflow
Within this demo we’re going to see once again how Dapr and Camunda Platform 8 works well together and provide language agnostic approach. In this case with...
Some thoughts and experience from implementing domain driven design
A lot happened this and last year, so why not to share some thoughts and experience from implementing domain driven design on an existing monolithic application. Sounds like a nonsense already.
Warning: it’s just a high level overview and probably will not make much sense without experiencing similar issues.
About the project
I’ve been mainly working on an ERP system called TCIS for a Czech manufacturing company engaged in processing metal sheets and profiles.The system consists of several modules like Customers, Suppliers, Base Items, Stock, Deliveries, Reporting and others. pTechnically, backend it’s written in C#, .NET Framework 4.7, MS SQL database and Entity Framework as ORM, dependency injection everywhere.
Web frontend is written in DotVVM, Javascript and is using SignalR, mobile frontend is in Xamarin and communicates with backend using web api and couple of external systems too.
To simplify typical common tasks used in forms (get list, display detail, update and save) we made a plugin to VS to design data using generators (dynamic data). pSo the customer can even design and update forms directly by himself. All extendable with events of course.
The solution contains common patterns, like facades, services, repositories, separated data, business and presentation layer, all via interfaces and dependency injection, not bad at all.
The issues
Now after a few years as the system grows up and business requirements are changing over time suddenly the system became very hard to maintain. One service now calls another service in a different context. Adding more if-else clauses only makes the problem worse. Changing one part of the application results in braking another part. Have you already been here as well?
So we decided to split functionality into modules (domains) in a microservice style, but with all the benefits from monolithic application for small teams (one solution, easier deployments). But to succeed, we must be very careful: Don’t touch code outside of your domain directly!But then, how to access data from another domain?
DDD and CQRS
Reading data is simple. Use queries to retrieve data from the database (either from views or tables) and transform into some DTO objects.Updates are a bit more complicated, but not too much. Since we don’t want to use CRUD anymore, but strict DDD, there must be another DOMAIN layer to keep that logic.
Upon each change the domain object generates a domain event, which is handled by: 1/ event handler in repository - to persist changes to DB 2/ domain event handler - to perform another task. It can be whatever, some work on the same domain, enqueue a new integration event or something else.
Thanks to Jimmy Bogard and his Mediatr on GitHub, which makes implementation very straightforward with Commands and Notifications.Many modules are now already separated and code is much easier to maintain.
Testing
Since we now have simple domain objects without additional dependencies, unit testing becomes a lot easier! No excuses anymore.
Event Sourcing
Thinking further. When all events have their own handles, why not to use event sourcing! The idea is it save the event first, then replay it.However, it’s a bit overhead on this project and doesn’t bring any customer value (apart of us geeks to try this juicy approach).We didn’t implement it.
Message Queue
With an optimistic assumptions about importance of queues and amount of data being processed, I decided to build my own on SQL.After some time it turned out to be underestimated. I mean, it works fine, but not worth the effort and not bullet proof. I’d suggest to use some existing queue, even MSMQ, anything, custom queues will never be so perfect.
Lessons learnt
DDD is must simpler when starting from scratch. Implementing it into existing projects is very difficult.
Relational database is not the best option for DDD due to the fact, that it’s the aggregate root, which is loaded and it may spread across many tables (yes, we can always create views).
On the other hand, NoSQL databases are designed exactly for this purpose and may be a better choice.
With CQRS you can always build read model in relational SQL.
2023
Another demo of Dapr and Zeebe (Camunda)
After some time I went back to Dapr (v10) and Zeebe engine used in Camunda Platform 8. Updated projects to .NET 7 and tried again what I learned before and r...
2022
Greetings to Camunda, Zeebe and Dapr!
It’s awesome to see how Dapr and Camunda workflow engine work well together. By using BPMN and DMN we completely remove business logic from the code and only...
2021
Are your class constructors heavy?
One of OOP principles says, that every class should enter valid states only. The bigger class it is, the harder to do. Typically we use class constructors so...
2020
Some thoughts and experience from implementing domain driven design
A lot happened this and last year, so why not to share some thoughts and experience from implementing domain driven design on an existing monolithic applicat...