Re: Learning DDD by doing ..

Thanks for you reply Paul ... thoughts inline. And spelling corrections :)




On 29 May 2014 17:31, Paul Rayner [email protected]
[domaindrivendesign] <[email protected]> wrote:


>
> How important is it to keep track of individual animals, or is it mainly
> important to know if it is a herbivore (spelling) or carnivore? I would
> consider creating Animal objects which know what kind of animal they are.
> Then decide on whether Animal is entity or value object based on the answer
> to the first question.
>


I would say it is important to keep track of individual animals, since we
are trying to plan the movement of animals temporarily--for maintenance of
an enclosure without animal disturbance. Without the "state" of the zoo,
i.e. where animals are located, we would not be able to come up with a
clear plan of action. Or more precisely, if we did not keep track of
animals, the first thing we'd have to do is define the whole zoo over and
over.





> Don't zoos call them "enclosures"? I would consider making each enclosure
> a first-class concept (ie. represent as an object) and see where that takes
> you. Then Enclosures could know whether they are fenced or not.
>
> Moving an animal seems like it might be an important event for your
> domain. But aren't you more concerned about whether a move is actually
> allowed before trying the move? You don't want to have the zebra eaten,
> then say "oops. I guess that wasn't the right thing to do!"
>


Yes but I got the impression that entites/aggregates validate themselves,
so I was thinking that this is more a Command-UI-Application service level
thing; just try and move and if it doesn't work present the result to the
user.


I will try and refactor to value objects more, and see where I get, thanks.


What about my questions Q1-Q4, did you have a think?






> Paul.
>
> On Thu, May 29, 2014 at 8:23 AM, Olof Bjarnason [email protected]
> [domaindrivendesign] <[email protected]> wrote:
>
>>
>>
>> Yes OK I can be more concrete. Here is some pseudo code domain level
>> tests based on the model I came up with, to get started...
>>
>> Baking questions Q1-Q4 down below.
>>
>> // Rule 1. Carnivors and herbivors cannot live together.
>> // For example, moving a lion to an enclosement with a zebra is not good,
>> since the zebra will be eaten.
>> zoo = Zoo()
>> zoo.add_fenced_enclosement('Fenced area 1')
>> zoo.add_fenced_enclosement('Fenced area 2')
>> zoo.add_carnivor('lion', 'Fenced area 1')
>> zoo.add_herbivor('zebra', 'Fenced area 2')
>> assertThrows(zoo.move_animal('lion', 'Fenced area 2'))
>>
>> Q1: I'm afraid of having an "explosion" of APIs in the Aggregate Root
>> zoo, since I'm actually encoding the kind of animal (carnivor, herbivor) in
>> the APIs name, and same for the kind of enclosement. Should I have some
>> value object instead? Is this an unwarranted worry, and it's nicer to not
>> have a clutter of types at this abstract level?
>> Q2: There's a lot of string IDs here - not value objects IDs which seems
>> more "DDD"-style. Unwarranted worry?
>> Q3: The word "add" seems very inprecise... Unwarranted worry?
>>
>> // Rule 2: Herbivors can live side-by-side.
>> // Moving a giraffe to the enclosement of an elephant is OK, since both
>> species are herbivors and wont kill each other.
>> zoo = Zoo()
>> zoo.add_fenced_enclosement('Fenced area 1')
>> zoo.add_fenced_enclosement('Fenced area 2')
>> zoo.add_herbivor('giraffe', 'Fenced area 1')
>> zoo.add_herbivor('elephant', 'Fenced area 2')
>> zoo.move_animal('giraffe', 'Fenced area 2')
>> verify_domain_event('animal moved', {animal:'elephant',
>> enclosement:'Fenced area 2'})

>>
>> Q4: This seems like a proper domain event, that an animal actually moves.
>> Would you model it like that too?
>>
>>
>>
>>
>>
>>
>> On 28 May 2014 17:01, Rikard Pavelic [email protected] [domaindrivendesign] <
>> [email protected]> wrote:
>>
>>>
>>>
>>> On Wed, 28 May 2014 13:06:02 +0100
>>>
>>> "Olof Bjarnason [email protected] [domaindrivendesign]"
>>> <[email protected]> wrote:
>>>
>>> > 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,
>>> >
>>>
>>> Hi Olaf,
>>>
>>> I agree with you that your example is complex enough to explain some
>>> DDD concepts. Having taken a quick look at it, I've seen a few
>>> connections with the examples Mr. Evans provides.
>>> I personally think it's hogwash to say DDD is applicable only to the
>>> most complex domain - that looks like avoidance to face reality, which
>>> is that every domain becomes complex as you dig into it.
>>>
>>> Having said that, there is an obvious issue with your question, since
>>> it sounds like you want answers to unspecified questions. If you asked
>>> few specific questions instead of providing a link to a blogpost, you
>>> might be more lucky in getting some good insights ;)
>>>
>>> Regards,
>>> Rikard
>>>
>>>
>>
>  
>