How to go further
Just because the training wheels come off, doesn't mean the fun is over.
I had to make this and now there is no turning back.
You made it this far, good for you! I'll take the opportunity to describe a number of things you can do to learn more.
If you are anything like me, or most people I suppose, then it's going to take more than one activity and one shot at a project to make it have all the bells and whistles. My proposal is to continue doing hands-on work based on what you've seen. It should be able to sustain you for some time. Then, as you have something of your own in your backpack, you can start to truly take in the full extent of DDD and what has been said and thought.
I wouldn't be surprised if you "only" read the book. Not an issue!
Using the reference project, you could start adapting for new requirements, like being able to have multiple rooms and/or sites and/or time zones. Or anything else for that matter.
Identify what changes would be needed, if you need new Aggregates (or an Aggregate Root) or Entities etc. It should be possible to evolve such functionality without significant rework.
You could certainly take the starting requirements and build the application to the best of your abilities in your language/runtime and other technologies of choosing.
Why not just go all the way and do what I did (minus writing a book) and build an application based on your own requirements.
Make sure that you keep level-headed and objective and that you try to keep the phases clean — first the high level scenario to guide the project, then conducting the strategic DDD, and only after that proceeding to the tactical implementation work. You may of course iterate the cycles, but you'll have to role play a "business owner" type character while starting, unless you want it to possibly derail into being any old pet project.
A spin on this is to actually do a real (low-key) project, maybe for some friends or family, or some affiliation or group you are part of. Looking forward to reading about the Domain-Driven Bowling Club or Domain-Driven Church of Satan (Local Chapter) in the future!
Diagramming is a core skill of senior engineers and most architects. They allow, when they are good, an easy-to-digest and precise format. As an author, I find that it's often more accurate than text and faster to finish than writing, too.
The sad truth is that many diagrams that I've seen are miserable because of some combination of (for example):
- Mixed views in the same diagram
- Confusing, overall
- Inconsistent style
- Aesthetically displeasing
While these are just some of the many parameters that could go wrong, the _most pressing_** problem is that many times you are happy to have a diagram at all, in the first place**.
So: Diagram everything and make others do it too.
If you've been around the block, you might wonder "Should I just learn UML?". It's a rich and formal way of diagramming, but to be frank, few are orthodox about it. Most will learn the basics and then stay happy with what they took to heart, ergo, not all of it. But if you do want to go full UML, there's the GitHub repo for Learn UML2.* in simple terms. On the book side, the classic book on the subject is Martin Fowler's UML Distilled.
For models and tools/frameworks beyond UML, consider:
For software tools, you might want to consider:
My personal picks are Excalidraw for online collaborative whiteboarding and Diagrams.net for professional work that I can predominantly work on solo and then share as a file asset. Diagrams.net works perfectly fine for both UML-style diagrams and your typical free-form diagrams.
No sane person suffers through manually making sequence diagrams in a typical drawing tool; use WebSequenceDiagrams instead.
Write. Either for an own project, something at work, an open source project, or whatever really. Just write. We all learn it in school, but—and I know I am hard here—an engineer or architect who cannot write or communicate efficiently is not worth their salt. Sad to say, but that quality is not something I experience a lot...
As long as we have a business/tech split in a project or organization, whatever side you are on will always be easier to work with—if you are a techie, you could start using the tactical patterns right now. But what good will it make, beyond maybe just being a more disciplined refactoring of whatever code you already have?
That's why I think you should spend time building the circumstances to enable effective collaboration between the most important groups, so that you can actually create the core semantic artifacts and have these in a documented format.
Starting where you are now should makes this less scary, and you probably already have an idea of what's going on around you.
With the ubiquitous language defined, perhaps it's time to scale up and go for the full monty? In that case EventStorming could be an option. The ideas are easy enough, and as always, good facilitation might be the biggest requirement that's not listed upfront.
Either ask someone who has done this before, or accept that we all learn by doing and just do it. The book is cheap, you can always learn-by-video, and there are plenty of good articles describing how to run a workshop.
As stated in the beginning of this book, I really see no other way to be good at designing software than, well, by designing software.
While it's easy to get lost in all the specific services popping up in the vast arsenals of AWS and their ilk, you should abstract from individual services to broader capabilities. To be better prepared doing so—don't get surprised now—I have a book recommendation. One book that I find has been very good at tying together the last 10-15 years of development practices and modern technologies into one concise overview is Continuous Architecture in Practice: Software Architecture in the Age of Agility and Devops (Erder, Woods, Pureur 2021). Don't expect to go deep-diving here, but as inspiration to see the big picture that book might do the trick.
Designing is more about process and thought than about a given artifact to represent it. If you want to design as part of "exercise" then consider learning or using tools listed in the
And of course: Don't forget to build the things you design. Nothing is quite as powerful in conveying the learnings as feeling the pain yourself.
You might want to take the chance to also brush up on actually presenting the work:
Combine this with the diagramming work as needed.
There's excellent and more condensed material available these days than in the days of yore. It doesn't replace the original texts as much as it offers a more accessible path for many readers.
Perhaps this "DDD in 2 hours" type of thing started with Vaughn Vernon's Domain-Driven Design Distilled (2016). For a not-quite-so-thin book, I recommend Vladik Khononov's Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy (2021). It's easier to get into (and through!) than the blue and red books and it's very good in its own right. Like this book, it has to skip the deeper stuff, but that's precisely why I think you should start with Khononov's book.
A stellar resource, especially if you are in the .NET world, is Microsoft's online book .NET Microservices Architecture for Containerized .NET Applications. The link takes you to the (big) section dedicated to DDD. I'm happy to see Microsoft be so clear with how DDD supports modern software development.
This might feel really odd—having these distinguished sources at the very back of list, like this. Almost sacrilege? No, I don't actually think so. The primary sources are very, very good in my opinion but they require a bit of investment in time.
These are unmistakably "the real deal" and like we saw in an early page, DDD as a concept does not always reflect the true intentions of it. When the day comes for you to go to the root, there is no better way to get things straight than reading Eric Evans' Domain-Driven Design: Tackling Complexity in the Heart of Software and Vaughn Vernon's Implementing Domain-Driven Design.