If you know me in person, you most likely already know that I'm batshit crazy about DDD (Domain Driven Design, not Degenerative Disc Disease ...). As DDD is the kind of topic everyone speaks about but only few actually use this method in practice, I've decided to share some real-life lessons learned with The Internet (I mean you: The Reader). It doesn't mean that I find our approach as fully canonical and 100% by-the-book (The Blue Book) - but what we do works for us (in a really complex scenarios) and brings true benefit: that's what it supposed to be about, right?
The Crusade for Ubiquitous Language
- Don't expect the language of domain experts to be unequivocal - it's not like ubiquitous language just lies somewhere there and waits for being discovered - experts sometimes have 1 word to describe various entities
- and yes, it causes problems
- and yes, they're used to live with them
- and yes, it doesn't mean you have to copy that into your model
-
Even if you've got the full consensus of every team member about how particular entity should be named, it means nothing if in the next conversation you use the different noun to describe it. It's the best indicator that you've all been wrong.
-
If you're questioning whether particular entity should even be in your model or not, just think whether it occurs in business expert day-to-day conversations. If it does, keep it - even if it doesn't make much sense at the first glance.
The stuff 'in between' and multi-dimensional hypercubes
- Relations between entities may be exactly as important as core entities themselves:
- because they may validate and / or constrain the model
- because they may be the carriers of additional information as well
- because naming them makes the model easier to understand
- Watch for same (?) entity that appears in different contexts / dimensions. For instance:
- an entity may appear as an instance in particular period of time (or more periods of time)
- and the same (?) entity may also appear in a continuous aspect that links its representation in those periods of time
-
If your project involves more than 4-5 people that do active development, make sure that you distinguish shared domains, especially if they are core ones - otherwise nothing can save the coherency of the final solution.
-
Examples, examples - bring more examples on board! They are as good as concise way of describing things as drawings are (and sometimes even better).
Brainstorming and the silence after the storm
-
Everyone is super-creative during the brainstorm and people come up to awesome ideas when their thought potential is combined. But once they part their ways to do the usual job, the outcomes should be documented ('snapshotted') in a way that will help them with re-playing the reasoning path so the outcome of the discussion is not lost. I know it sounds odd -> (how can all of them forget what was discussed in detail if they were engaged seriously?), but believe me - once adrenaline rush drops down and people switch context a few times, a lot of what was discussed vanishes from their heads.
-
I can't emphasize it enough - keep everyone engaged, involved and up-to-date:
- avoid discussing the pre-prepared (off-stage) drawings - because people will miss the whole reasoning that happened 'during the journey'
- don't brainstorm in groups larger than 5-6 people: if you have to involve more people, do it gradually: of course it means that you'll have to repeat a lot of talk and re-draw some things from scratch, there's also some chance for waste, but groups larger than 6 people aren't really productive during modelling brainstorms
- listen, listen, listen - if you tend to smother other people just because your position is higher, you speak louder or you're more self-confident, you're just being destructive
- One of the most painful mistakes is re-drawing someone else's drawings just because you didn't get them. Surely, you can do that as an exercise for your own purpose, but don't question someone else's work in that way - it's a total lack of respect and killing other person's ownership. You can still ask for clarifications or suggest corrections, but NEVER EVER start from scratch just because you don't want to bend your brain a bit.
To be (quite likely) continued ...
