In my latest post I mentioned the quote from Evans book. I met quite a lot of people interested in DDD, that either missed this quote or didn’t realize how significant it is. Yet, I think this is the single most important thing you should understand before you even attempt to start doing DDD. Even more so if you want to advocate it in your company and drive the adoption.
DDD is hard. Not because it’s complicated. In fact it’s a rather simple idea. Not because you have to be another Evans to get any value out of it. You can do a lot of tiny things, right where you are now, starting today. Not because there are no materials available or that the good advice is given only to the chosen few. Everything’s out there, easy to find, a lot of useful things you can get for free or pay a few dollars for a book.
I think that DDD is hard for two main reasons – it requires a completely different skillset than what is normally expected from developers and a completely new way of thinking. You need to become the soft geek and watch out to not slip into the more comfortable mode.
The soft skills can (and should!) be learned, also by means of formal training. There’s really a lot of good material out there on Emotional Intelligence, motivation and goal setting, communication, dealing with conflict and leading change. At the end I put links to my favourite resources, in my preferred “geeky style” – very pragmatic, based on solid research, with advice specific enough to get it into practice right away. I’ve gone through every one of them more than once and intend to do it again and again. I learn something new every time. But this is the easier part, if you know what you’re looking for, then eventually you’ll find a way to get it.
The other problem is that the way you approach DDD is very counterintuitive, it’s different from what usually works for us, it’s very, very, very uncomfortable (it really is!!!). There are some experts, but you need to learn to be your own expert, because DDD is messy and very sensitive to the context. What worked for Evans, might not work in your project. You can’t really get a good answer to DDD-related question on StackOverflow. There’s no book or a flowchart that will help you with making decision. You need to learn to observe, listen, become more self-aware, recognize hidden assumptions and… your own biases.
Evans casually mentions that the technical talent usually prefers to work on elaborate frameworks, rather than solve domain problems. Rather than treat software as a tool, means to an end, we learn to use it as a universal hammer. This is how we work, this is how we provide value, this is what we’re proud of doing, in essense – this is who we are.
Learn to see it, notice limitations it introduces. Then start asking why, why, why? Don’t be afraid to take a couple of steps back and question everything you “know” to be true. You might feel uncomfortable, because you suddenly stop “getting things done”, you feel unproductive. Even though you understand on an intellectual level that this way you provide more value, it’s still challenging on the emotional level.
When I first started asking a lot of questions, every single task was taking a lot of time. We had lots of meetings and discussions. Some colleagues told me that if the customer can’t get the requirements right, then it’s their problem, we should do our best, the way we understand it. I didn’t agree. I worked my own way… and felt very unproductive.
After all those discussions some work was even dropped, because we realized that it was in the backlog for too long and it wasn’t relevant anymore. It happened once for 3 tasks in the row. So my colleagues joked that they will give to me any task that they didn’t want to do and maybe I’ll convince customers that we shouldn’t do it. It was funny, but also… After a few days of work I had nothing to show, no results, no feature shipped. All those meetings and discussions were demanding, I had to think how to explain things, watch out for assumptions to question. It would be so much easier just to do as I was told and do my best to interpret requirements without asking any questions. If something was wrong, they’d have noticed, right?
There were other things too. Since I’m an introvert all that extra communication cost me a lot of energy. Some days I was literally exhausted, after work I just wanted to sit alone in my room and don’t talk to anybody. Then I didn’t know how “those things” should be done. I was new to the system. I asked a lot of silly questions, quite a few times felt like a total idiot and promised myself that I won’t ask any more. Then I felt that I’m simply annoying because I give all those people lots of extra thinking, extra work, they surely must have hated me for this, not to mention that I slowed down the whole process.
For some reason that I can’t explain I believed this to be a good approach. And over time it started slowly paying off. We had an important project that involved changes in 30 different systems at the same time. My team worked on only 2 of them. The project lasted a few months. We managed to catch a few important misunderstandings at the very early stage of the project… and then we wasted the whole day discussing how to ensure data is consistent at the end of the “processing window”, only to discover that the business is ok with temporary incosistency. We insisted on having enough time for tests and consulted test cases with business. We caught a few other misunderstandings. The project was successful, there were maybe 3 bugs found in the business testing phase (compared to literally thousands raised for those other 28 systems). Questioning everything and talking to business weren’t the only reasons for success, but I know that if we didn’t do it, we’d probably miss those misunderstandings and they’d be discovered at a very late stage. We had enough time to find alternatives and we avoided re-work.
Still… I changed jobs, went to another company at the opposite end of the world, worked with a different client and it all started again. Feeling like an idiot more times than I dare to admit, doing things differently than they “were done there”, not sure if and how fast I can show that it actually provides some value…
It’s so much easier to disconnect and just “do as you’re told”, hoping that somebody else will make sure we’re working on the right thing and get the requirements right. Once you get involved, you also assume more responsibility, it’s not “somebody else’s job” anymore. It’s also so much easier to focus on all the patterns, discuss superiority of repository over static CRUD-like objects or hold endless modelling sessions, looking for the perfect model. The trouble is all that doesn’t really matter if you work on the wrong thing. Doesn’t matter how perfect your model is, if you focused on some unimportant part of business and don’t understand the domain.
So be prepared. Quite likely, you’ll be a lot out of your comfort zone, doing things you have no idea about, pretending that you actually know what you’re doing, learning a lot from your own mistakes… There will be lots of them. Maybe some colleagues will get angry with you, they will tell you that what you’re doing is silly and a complete waste of time. Worst of all, they might be right, especially in the beginning. But you won’t learn all this just by reading a book and sitting in front of your screen all day. You can’t really learn all those things by doing your pet project, using some made-up requirements. You need to accept the discomfort and start learning those crazy things. The good news is, some day it won’t be that hard anymore.
Recommended materials:
“Influencers” great material if you want to lead the change in your organization, even if it’s “just” promoting automated tests and clean code
“Crucial conversations” absolute must-have on difficult conversations with high impact
“Crucial accountability” on how to keep each other accountable without ruining the relationship and being a jerk
“Succeed” a great book on goal setting and motivation (with the silliest title ever:)), solid research, no usual motivational crap, pure science and practical advice
“Inspiring Leadership through Emotional Intelligence” a Coursera course that proves that Emotional Intelligence can be learned and improved, fantastic material on how to listen better and how to avoid burnout
Thanks for this great article, Weronika! And thanks for the recommanded materials. It sounds really interesting!
Trying to discover a entire domain alone is really painful and you’re right, this is where DDD is so damn hard! That’s why, whenever it’s possible to do so, Event Storming sessions will help you A LOT.
You won’t be alone anymore 🙂
During Event Storming feeling like the dumbest person in the room is part of the game 🙂
As Alberto Brandolini (@ziobrando) says: “Event Storming implies breaking some rules and assumptions, doing something unconventional, and occasionally feeling stupid” this should remind you something 😉
The difference is that you won’t be alone anymore and it will definitely more funny!
Thanks Maxime, I wasn’t aware that Alberto said that. That sounds really interesting, I’ll definitely look into ES more!
Have you tried it yourself or just take his Alberto’s word on that?:)
Well to be honest, I did not have the chance to practice ES on a “real” project. But I did participate in several ES workshops (including a one day workshop with the master himself!). I also teached ES to a couple of colleague during lunchtime where we did model a fake application (one of us was playing the role of the BA).
That’s why I’m kinda an ES evangelist. This is really powerful and brings you a lot of different valuable outcomes!
DDD is hard because:
1. You probably don’t need it and wont benefit from it ever. If you’re doing something you don’t need to do then you’re going to have a hard time figuring out what to do when doing it. You’ll find DDD is more ritualistic than productive.
2. DDD introduces a lot of problems. It requires you to create an entirely independent middle layer of modelling that is almost impossibly decoupled from things such as persistence. The remaining layers of DDD are also very rigid and unaccommodating. DDD creates a lot of separation that can make it very hard for parts of your code to talk to each other.
3.Everyone has their own take on DDD and guides out there really don’t make matter simple. People are really doing it as a fad. That means most examples aren’t using it for good as aren’t really demonstrating anything. The rare cases where DDD or a take of it might produce results are drowned out.
In most cases you don’t want DDD. You just want a model that maps to whatever IO you’re talking too as best it can and that caters to it as best you can. You already have all your structs defined by your IO layers so just make services that work with those.
DDD was never intended as a standard way of programming. It is expensive and gratuitous. It is like trying to somersault all the way to the shops while juggling a dozen eggs. You should never do it or anything like it until you encounter a problem that might need it.
Hi Joey,
Sorry for a late reply, I missed the notification :/
I think you raised some good points and I agree with most of the things you’ve said. In particular that everybody has their own take of it. Also I agree that you won’t benefit from something you don’t need, in my experience the more “technical” parts of DDD proved to not be so useful.
However, I disagree with the second point. I worked on projects where introducing that additional layer actually simplified things, made the complex logic more testable, etc. I have to admit there were also projects where it was the opposite, though.
As to whether this will ever work and in what projects or whether this was intended as a standard way of programming, I think it’s hard to argue without having a specific project and team in mind. As you said, everybody has their own take on it 😉 For me learning about those concepts proved to be very useful in a few projects, I’m sure some of the DDD experts wouldn’t approve and certify them as “done properly” but who cares? It helped me deliver more value to the users and at the end of the day I think this is the only metric that truely matters 🙂