Re: Re: Nested immutable value objects

There are a lot of argumentations about the evils of setters, around the web
But the main one, in DDD, is that you create an aggregate to keep business
invariants, and you can't grant such invariants if your clients can access
and change the aggregate state via setters.

As for the convoluted example, you are right it's overkill for a Car, Tank,
Liter example. But that was just to show you the syntax you would get.

You can of course use a more procedural way to implement gasUp (lower camel
case makes it Java, doesn't it? :-D), but that will not be cleaner than my
functional proposl.


But given that, this is not the way to go. Just the way I use in my models.
:-D


Giacomo


On Wed, Mar 20, 2013 at 7:09 AM, Tom Eugelink <[email protected]> wrote:

> **
>
>
>
> I'm quite new to DDD as a development technique; the concept of modelling
> the domain totally separate of any context, seems like like 'the way to go'
> in software engineering and I have been developing software like that for
> many years, by just following my own gut feeling principles. And they
> worked quite well for me so far, but I still use setters.
>
> I can understand that setters are questionable, and that in this example
> "gasUp(new Liter(50))" (hey, Java ;-) or "drive(new Miles(10))" are the
> better way of modifying the entity. But I also know that setters are
> required a lot of properties because the have to be set from some form,
> like a car's registration. Or is that whole do-not-use-setters thing just
> syntax, like a "register('12345')" actually is a "setRegistration('12345')"?
>
> The example you've giving with using all lamba's feel to me like overkill
> and losing the 'natural' way of handling entities. Is there any
> documentation / argumentation why that would be the way to do things?
>
> Tom
>
>  
>