Re: Learning DDD by doing ..

Hi jorge!


Thanks for you long and thorough answer.


I know all of the things you say from a theoretical perspective - but with
the toy problem I wanted to practice applying those ideas, doing some
design. Since I got stuck quite fast when actually sitting down and trying
to draw a model, and write some code, I thought I'd like to see how someone
experienced with DDD would go about designing a model for the relatively
small problem I presented.


Also curious to know what part of the zoo problem is not complex? Compared
to e.g. a shopping cart web application, which seems to be a popular
application of DDD by just googling around, I'd say it is "complex" (that
word is a bit fuzzy, isn't it?). It could easily be extended to include
number of animals per enclosure constraints, or more automatic
planning/scheduling features, or whatever, if you think it is too easy
right now.


Regards,




/Olof




PS. Here is the problem description for those that didn't follow the
initial link:


We are developing a system to help a Zoo plan annual maintenance. E.g.
doing annual cleaning of a fenced garden is something you want to do
without having a rhino chasing you, or changing the broken light bulb is a
job done best without a monkey picking your tools from you.


In the first iteration of the software, we agree with the zoo owners that
just being able to decide whether or not a specific animal can be safely
moved from one enclosement to another is the most important task the system
has to help out with. Later on we might extend the system to include
automatic computation of the "best" plan possible based on some idea of
what is best - e.g. minimizing number of movements, or similar criteria.
But that is later on.


We need to understand how to move animals around safely, so that we can
setup a schedule of movements to clear out one enclosement at a time. Here
are the rules governing movement of animals.


More details, e.g. the constraints for moving an animal -
http://objarni.wordpress.com/2014/05/27/ddd-toy-problem-the-zoo/


DS






On 27 May 2014 23:50, Jorge Branco
[email protected][domaindrivendesign]
<[email protected]> wrote:


>
>
> 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
>>
>
>  
>