DDD, Micro Services, CQRS and an Enterprise Grade Chat Module backend
Do you want to know a secret? DDD and Micro Service Architecture is actually ridiculously easily understood once you simplify the concepts a bit. No need for paranoia, it's all about COMMUNICATION!
Join the DZone community and get the full member experience.Join For Free
A couple of years ago I wrote an article here creating so much fuzz I felt as if I had been cursing in a church. The idea of the article was that you could teach yourself DDD or Domain Driven Design in 5 minutes. In this article I will revisit DDD with an example use case, illustrating not only how you can learn (the most important parts of) DDD in 5 minutes, but also throw in Micro Services for fun - While at the same time giving you an enterprise grade chat module backend, you can build a frontend on top of yourself, and throw in CQRS for laughs at the end. But first watch the video.
Did you notice how easy it was for me to show you and talk about the core concepts of the chat module's backend in the video? That is because as an integrated part of my development and design phase I declared a language. This is what is called a bounded context in DDD. By declaring what words and phrases implies from within the context of my chat module's backend, communicating about what it does becomes easier. Below you can see my definitions.
This makes it easy for members of your project to communicate about features since it avoids having words imply different things for different team members. The word "client" for instance typically imply something completely different for a software developer than what it does for your marketing department. Hence, by starting out the project with a dictionary of shared terminology, you can more easily avoid misunderstandings. Any schmuck can create a chat client. Few people can implement one such that other developers and non-developers understands what it does, how it does it, and why it does what it does. The art of software development is first and foremost about communication. If you cannot adequately communicate with your team members, how skilled you are at algorithms and data structures becomes irrelevant.
1. Declare a language
In software design an actor is typically a human being interacting with the system somehow. We as software developers tend to break down actors into classes or roles. For instance, in the above chat module, there are 3 primary types of actors.
- A client or prospect wanting to chat with an admin
- An admin answering chat requests from clients
- A superuser being a superset of the admin role
Working out the actors in a system is typically a subpart of creating the linguistic definition which we did further up, but it often helps to break the actors down into its own sub section in your design documents and your documentation. You can see an example of how I did this with the chat module.
2. Declare your actors
Verbs are actions the actors can do with the system's objects. Breaking these actions down into verbs, and associate these verbs with your linguistic definition, makes understanding what your system does much easier. To see how I created my action endpoints around verbs, see how the URL of my endpoints are created such as for instance "session/take" allowing an admin user to take responsibility over a session at the following parts of the documentation. Everybody immediately understands that this is about a "session" and it's about "taking it" - Hence, due to the previous definitions I created in section one above, documenting the endpoint and what it does becomes almost superfluous at this point.
3. Actions are verbs actors can do with objects
As you are reading this paragraph, you're probably around your fifth minute of reading I imagine - Yet still you've now got a thorough and deep understanding of the most important parts of DDD, being of course communication. To create working systems in collaboration with others, is first and foremost about communicating. Once you can communicate well about the system and its design, the implementation becomes painless, ensuring both its developers and the business parts of the company understands what they are going to build, ensuring the system is delivered on time, well functioning according to its specifications, without negative surprises. And as an additional kicker, once you understand how the backend was tied together, you're also halfway through understanding Micro Services. As an additional bonus, I have also taught you CQRS due to the way messages are published, arguably "segregating" the act of reading data from the act of creating data. Not bad for an average Sunday if you ask me ^_^
- DDD - Check
- Micro Services - Check
- CQRS - Check
Hence, I have now taught you Domain Driven Design, CQRS, and Micro Services, and more importantly I did it in 5 minutes ^_^
Sim Sala Bim, you now know DDD, Micro Services and CQRS
Opinions expressed by DZone contributors are their own.