Re: Learning DDD by doing ..

Olof,

I've been (or better yet, am) through the same situation and from the
(little) understanding I have, I gathered some points that might be useful
to you:

a) DDD applies especially well to highly complex domains. From what I
gather about your circumstances, a problem you will face is that a lot of
what's to gain from using DDD simply cannot be understood using simple toy
domains without looking highly contrived. For instance, if you find
yourself wasting a lot of time doing simple plumbing work in your system
just to follow the tactical patterns, you may be applying DDD to the wrong
project (or maybe you can skim over the tactical patterns, just use the
strategic ones).

b) Arguably the central aspect of DDD is the relationship developer-domain
expert, the idea being that you should gather as much information as
possibly directly off the domain expert (preferably with no
intermediaries), in an iterative process, for as long as you find there's
still a decent ROI. This may sound dead obvious, but actually isn't (or
wasn't) a practice followed by the typical company. Again, this can hardly
be captured in a toy example.

c) What's your main focus at the moment? Learning about the strategic or
domain patterns? I'm asking this because although I find the strategic
patterns to be generally applicable to most complex domains, I find at
least some of the tactical patterns most suitable to a subset of those
applications (database / distributed applications, I'd say). I may be
totally off here, be warned.

d) *I'd say the higher returns of applying DDD occur when you have a set of
concrete use cases that imply a complex model. *You will grind the use
cases up and down with your domain expert until you really understand the
model and your use cases. When this happens and you're lucky, you may be
able to decompose (distill) your system in a way that was not obvious at
first, but that responds perfectly well to your use cases.

In this moment you will start seeing that maybe a lot of relationships
between domain concepts, although existing in the real world, don't need to
be modeled at all. Maybe what you call X can be better understood by
splitting it into an X in domain alpha and X in domain beta. Maybe a lot of
supposed domain concepts can just be thrown away from your "write"-models,
because your use cases don't really need them. Maybe a lot of domain
concepts that must be included in the application are actually only
UI-related (you only have them because you have to show them in the
UI/reports). Get rid of them from your write-models, as they only add
complexity to them with no clear gain. Try to squeeze out the most of the
information you've gathered, trying to simplify as much as possible.

This new way of seeing things allows you to express what you need to do in
your system in a very easy/elegant form. It could not have been done
without a deep understanding of both your business domain and your concrete
use cases. Remember, you are not modelling the real world, you are
developing a specific application that targets specific goals. You want to
develop your system for your use cases. And again, this is something that
you will probably lack with a toy example. DDD is all about domain
discovery. You won't get the most out of it when you "cheat" by creating a
domain model suited to what you think you will need. You gain when you are
surprised, because you could not foresee what you actually ended up getting
as a domain model had you not gone through the trouble of understanding it
deeply :)

I reckon this is not the answer you were looking for (almost none of the
answers to my DDD questions were what I was looking for and I hated it. Now
I understand why).

jorge



On Tue, May 27, 2014 at 10:35 PM, Olof Bjarnason
[email protected][domaindrivendesign]
<[email protected]> wrote:

>
>
> Hi!
>
> I'm new to the list (and DDD), and have been reading articles a lot
> last week or so about it. Very interesting topic!
>
> So the other day I thought I want to start actually applying some of
> the ideas I've read about, but first I needed a domain to model. Of
> course I could have taken the bald step and tried to model a
> subset/bounded context of one of the (legacy products) I'm working on
> in my day job, but I soon felt it was too overwhelming to start even
> (cannot see forrest because of all the trees being one feeling I had).
>
> Instead I sat down and thought out a "toy problem" to play around
> with... It's about a zoo and the yearly maintenance they need to do on
> their enclosures (cages, fenced gardens and so on).
>
> When I had done that, I immediately sat down and started hacking, and
> hit a brick wall almost instantly. About a million design questions
> showed up, and I thought "why don't I ask some experienced people how
> they would design a domain around this problem instead"? It should be
> simple enough given that the domain/problem is quite small...
>
> So please, if anyone is upto it, please tell me how you would use DDD
> on "The Zoo".
>
> http://objarni.wordpress.com/2014/05/27/ddd-toy-problem-the-zoo/
>
> Cheers,
>
> /Olof
>  
>