Re: Modelling a traffic control center

Hi Nuno, 

Yes, make sense, thanks!. 

So as a summary for your OO modelling technique is more or less:

1) Determine the event/transaction for the use case
2) Define roles around that event/transaction
3) Apply those roles to context concepts

At the time of defining roles do you always include person roles?

Cheers.

--- In domaindrivendesign <at> yahoogroups.com, Nuno Lopes <nbplopes@...> wrote:
>
> Hi Sebastian,
> 
> > OK, but I would see it more as Designee rather than Asignee just because an assignee is simple not assigned
unless a TrafficMap decides to accomplish the assignment. 
> 
> You need to settle on the business events you want to capture in the model. After this define the needed
roles around these events. In this case, the event is assignment (don´t confuse with Greg's events or
domain events). So in an assignment you have an an assignable object, a assignee and optionally someone
that gave the assignment (Manager?). 
> 
> So Balance balance. "Designation" does not seam to be a business transaction that needs to be captured in
this context. It seams to be Assignment only, unless you need to track failed assignment, in which case
Assignment would be a successful designation.

Re: Re: Modelling a traffic control center

Re: Adding entities to another, questions around basic example

Hi Nuno, 

I wanted to ask you something about:

> Say the operation: Move photo.
> Who moves the photo? The AlbumOwer. What us the photo in             > relationship to the albums when moving a photo? A
PhotoInAlbum. So   > the Photo is the AR of the Photo Aggregate when PhotoInAlbum is part > of.
> Album a = Albums.Get(ida);
> Album b = Albums.Get(idb);
> AlbumOwner  o  = AlbumOwners.Get(oid);
> Photo p = Photos.Get(pid).
> Photo.Move(ida, idb, o);

Since OO modeling is about observing real world, then why the Photo is the responsable for moving itself
from one album to another, instead of the AlbumOwner being the responsable for the movement? 

Album fromAlbum = Albums.Get(ida);
Album toAlbum = Albums.Get(idb);
Photo photo = Photos.Get(pid).
AlbumOwner albumOwner = AlbumOwners.Get(oid);
albumOwner.Move(photo, fromAlbum, toAlbum);

I think both solutions represent the same in terms of business, under both approches you can register the
Album Owner performing the move and registering the transaction/event "movement", among other things
but the one you suggested is creates couple between a photo and its album. 

This will be an eternal discussion.
Kent Beck in its TDD book preferd to create examples using coupled objects, having the "Money" class and
letting that "Money" class know the "Bank" class. On the other hand I once talked to an Smalltalk with lot of
experience and he prefers designing pretty functional and less coupled objects saying Kent Beck design
is not a good design solution in its TDD book.

Move(Photo, FromAlbum, ToAlbum) {
FromAlbum.remove(Photo);
ToAlbum.add(ToAlbum);
Movements.add(new Movement(Photo, FromAlbum,, ToAlbum));
}

vs.

Move(FromAlbum, ToAlbum, AlbumOwner) {
FromAlbum.remove(this);
ToAlbum.add(this);
AlbumOwner.add(new Movement(this, FromAlbum,, ToAlbum)); //or this
}

But given your example, does a Photo know the Album that belongs to?

class Photo{
private Album album; 
}

?

Cheers,

------------------------------------

Re: Re: Adding entities to another, questions around basic example

Re: Re: Adding entities to another, questions around basic example

Re: Adding entities to another, questions around basic example

Code Correction:

class Album
{
     ....
     void Add(AlbumOfItem p, AlbumOwner u)
     {
          p.AddToAlbum(this, u) // double dispatch
     }
     void Add(AlbumOfItem p, AlbumOwnerFriend u)
     {
          p.AddToAlbum(this, u) // double dispatch
     }
}

class Photo :  AlbumItem
{
     ....
     void AddToAlbum(Album a, AlbumOwner u)
     {
          ..... // you favorite business rule methodology .. I already gave examples of mine
     }
     void AddToAlbum(Album a, AlbumOwnerFriend u)
     {
          ..... // you favorite business rule methodology .. I already gave examples of mine     
     }
}

interface AlbumItem
{
     ....
     void AddToAlbum(AlbumOfItem a, AlbumOwner u);
     void AddToAlbum(AlbumOfItem a, AlbumOwnerFriend u);
}

Cheers,

Nuno

------------------------------------

Re: Re: Adding entities to another, questions around basic example

On 2009-12-03 03.21, Nuno Lopes wrote:
>> Since OO modeling is about observing real world, then why the Photo is
>> the responsable for moving itself from one album to another, instead
>> of the AlbumOwner being the responsable for the movement?
>>
> That is a very interesting question, that many have stumbled on and had
> opened many fierce debates (some of them philosophical) between soul
> mates :)

And the reason is that while arguing whether to go through door one or 
door two, the real answer is to go through door three. Problem is, noone 
knew nr three even existed!

Before you read on, check this out:
http://www.artima.com/articles/dci_vision.html

Done? Then continue below.

> *Quick answer*
>
> "Because the the photo may be moves by many parties, not just the owner"
> :))))
>
> You see, as the system evolves, other parties (say AlbumOwnerFriends)
> might be able to move photos around. Can you imagine implementing the
> move operation in each of them?

We might also invent other types of collections, such as "Events" and 
"Last month". All of these would probably involve the interaction 
"moving photos around".

> The operation of adding a photo to an album should actually be
> implemented by a Photo Role in context ... check bellow.

Two important words above: role and context! But one thing is missing...

The main thing that is missing is the interaction, as a first-class 
concept. Then it would also be a good idea to have the context as a 
first-class concept. If we try to model this scenario according to the 
principles outlined in the article above we might get that:
* "Photo" as an object implements a "Movable" role
* "Album" as an object implements a "Container" role
* There is an OrganizerContext which has several roles that can be bound:
Container from;
Container to;
Movable item;
User user;

With this context we might then have an operation move() which takes the 
object bound to "item", takes it out of "from", and puts it into "to", 
but only if the "user" is allowed to modify both "from" and "to" 
Containers. Something like this:
public void move()
{
   checkPermission(user, from, "write");
   checkPermission(user, to, "write");
   from.remove(item);
   to.add(item);
}

Now that we have this context, where the interaction is explicitly 
shown, we have something that no OO-based software to date has ever had: 
readable code that maps to the users mental model! If we want to find 
out what "move" in the UI actually does, here it is. Instead of having 
to split up this functionality into tiny little pieces, strewn here and 
there in objects, we gather it into one place. And, since the objects 
are bound using roles, instead of classes, we can reuse this interaction 
for any case that involves "Containers" and "Movables".

There was a great presentation about DCI by Trygve Reenskaug (inventor 
of MVC pattern) at the last Öredev conference. I hope the video will be 
up soon, because it clarifies a lot about this, and why current OO, with 
the spread-things-out-everywhere approach, doesn't work.

Of course a big issue with all of this is that classes are not really 
useful for modeling objects anymore, as an object needs to be able to 
have a whole bunch of roles instead, depending on what interactions it 
wants to participate in. This is why a mixin-based approach, like Qi4j, 
is absolutely necessary. Other languages have this built-in, which is 
nice (although not necessarily helpful), but in Java the only way to do 
this properly (AFAIK) is by using Qi4j and Composite Oriented Programming.

/Rickard

------------------------------------

Re: Re: Adding entities to another, questions around basic example

Richard, where would you place the "move" method? A service outside all of 
the objects?

> Now that we have this context, where the interaction is explicitly
> shown, we have something that no OO-based software to date has ever had:
> readable code that maps to the users mental model!

This style reminds me of the "command" pattern in a message bus: you have 
one single place that orchestrates the actions on objects you pass it.

It also reminds me of some passage in the DDD book (which I cannot quote 
exactly abd possibly got it wrong): if you have an operation that involves 
many parties without a clear place to implement it, then put it in a domain 
service.

I am no OO-guru myself and listen very interestingly to this debate. Thanks.

/Jørn

----- Original Message ----- 
From: "Rickard Öberg" <rickardoberg <at> gmail.com>
To: <domaindrivendesign <at> yahoogroups.com>
Sent: Thursday, December 03, 2009 3:44 AM
Subject: Re: [domaindrivendesign] Re: Adding entities to another, questions 
around basic example

> On 2009-12-03 03.21, Nuno Lopes wrote:
>>> Since OO modeling is about observing real world, then why the Photo is
>>> the responsable for moving itself from one album to another, instead
>>> of the AlbumOwner being the responsable for the movement?
>>>
>> That is a very interesting question, that many have stumbled on and had
>> opened many fierce debates (some of them philosophical) between soul
>> mates :)
>
> And the reason is that while arguing whether to go through door one or
> door two, the real answer is to go through door three. Problem is, noone
> knew nr three even existed!
>
> Before you read on, check this out:
> http://www.artima.com/articles/dci_vision.html
>
> Done? Then continue below.
>
>> *Quick answer*
>>
>> "Because the the photo may be moves by many parties, not just the owner"
>> :))))
>>
>> You see, as the system evolves, other parties (say AlbumOwnerFriends)
>> might be able to move photos around. Can you imagine implementing the
>> move operation in each of them?
>
> We might also invent other types of collections, such as "Events" and
> "Last month". All of these would probably involve the interaction
> "moving photos around".
>
>> The operation of adding a photo to an album should actually be
>> implemented by a Photo Role in context ... check bellow.
>
> Two important words above: role and context! But one thing is missing...
>
> The main thing that is missing is the interaction, as a first-class
> concept. Then it would also be a good idea to have the context as a
> first-class concept. If we try to model this scenario according to the
> principles outlined in the article above we might get that:
> * "Photo" as an object implements a "Movable" role
> * "Album" as an object implements a "Container" role
> * There is an OrganizerContext which has several roles that can be bound:
> Container from;
> Container to;
> Movable item;
> User user;
>
> With this context we might then have an operation move() which takes the
> object bound to "item", takes it out of "from", and puts it into "to",
> but only if the "user" is allowed to modify both "from" and "to"
> Containers. Something like this:
> public void move()
> {
>   checkPermission(user, from, "write");
>   checkPermission(user, to, "write");
>   from.remove(item);
>   to.add(item);
> }
>
> Now that we have this context, where the interaction is explicitly
> shown, we have something that no OO-based software to date has ever had:
> readable code that maps to the users mental model! If we want to find
> out what "move" in the UI actually does, here it is. Instead of having
> to split up this functionality into tiny little pieces, strewn here and
> there in objects, we gather it into one place. And, since the objects
> are bound using roles, instead of classes, we can reuse this interaction
> for any case that involves "Containers" and "Movables".
>
> There was a great presentation about DCI by Trygve Reenskaug (inventor
> of MVC pattern) at the last Öredev conference. I hope the video will be
> up soon, because it clarifies a lot about this, and why current OO, with
> the spread-things-out-everywhere approach, doesn't work.
>
> Of course a big issue with all of this is that classes are not really
> useful for modeling objects anymore, as an object needs to be able to
> have a whole bunch of roles instead, depending on what interactions it
> wants to participate in. This is why a mixin-based approach, like Qi4j,
> is absolutely necessary. Other languages have this built-in, which is
> nice (although not necessarily helpful), but in Java the only way to do
> this properly (AFAIK) is by using Qi4j and Composite Oriented Programming.
>
> /Rickard
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

------------------------------------

Re: Re: Adding entities to another, questions around basic example

On 2009-12-03 13.52, Jørn Wildt wrote:
> Richard, where would you place the "move" method? A service outside all of
> the objects?

No, on the context object itself. The context is a 
instantiate-populate-invoke-discard type of object, so not a service.

But there are many ways to implement the basic pattern, and this is 
still being explored, so there's no right or wrong.

>> Now that we have this context, where the interaction is explicitly
>> shown, we have something that no OO-based software to date has ever had:
>> readable code that maps to the users mental model!
>
> This style reminds me of the "command" pattern in a message bus: you have
> one single place that orchestrates the actions on objects you pass it.

Except it's not really a single place. The methods for the interactions 
would be on the different contexts, which there would be many of. The 
contexts should map to the users mental model of the software, so it's 
hard to discuss them without understanding the UI.

> It also reminds me of some passage in the DDD book (which I cannot quote
> exactly abd possibly got it wrong): if you have an operation that involves
> many parties without a clear place to implement it, then put it in a domain
> service.

This is an extension of that realization.

> I am no OO-guru myself and listen very interestingly to this debate. Thanks.

Well, same here. I had a chance to talk to Trygve before his talk at 
Öredev (since I was doing a talk on how to implement DCI in Qi4j), and 
there were many new realizations coming just from those brief 
discussions. I think it might take awhile before we settle down on 
exactly how this pattern is to be implemented in different situations. 
The key point is that contexts and interactions should be their own 
thing, rather than being distributed into the objects themselves, which 
makes it very very hard to follow what's going on.

/Rickard

------------------------------------

Issuing commands