A good place to ask about DDD is:
http://www.sitepoint.com/forums/forumdisplay.php?f=147

Or, you can always join a discussion group:
http://tech.groups.yahoo.com/group/domaindrivendesign

Interesting. However i have some questions.

Let say, we have an user which can have photos albums.
We would have an User object with an albums attribute.

Now, we want to add an album to the user albums collection.

How can we do that with this approach ?

Creating the Album object and then invoke a addAlbumToUser(Model_User user, Model_Album album) from the userRepository ?

or invoke directly a addAlbumToUser(Model_User, title) from the userRepository which will create the Album object ?

or simply add behavior to the Model_User class like a method createAlbum() which will create an album object and add it to the user album collection ?

I admit, i have some difficulties to choose a way :D

It seems objects have not so much behavior, but Repository have.

(sorry for my frenchy english)

Thanks,
Cya, Benjamin.

The class User was only used as an example. Feel free to rename it to whatever you think reflects better your understanding of the domain, or define a new class based on the context within which this model applies :)

> Not really. The repository is also responsible for talking in aggregate roots.

But what does that mean, “talking”?
As the (known) article also, and only, states, it is responsible for persisting the whole AR. But that’s only one opinion and some other DDD gurus like Greg Young, tell us:
[A repo...] provides the domain collection semantics to a set of aggregate root objects.

Also some tend to say that it’s not the responsibility of the repository to persist anything. Because Repos are the abstraction of objects in memory. Therefore they do live always and don’t have to be persisted. In languages like PHP you’d have a problem with that, though.

The main question is:
If domains should be persistence ignorant, why they would need to have a repository that persists anything?

> User is part of the negotiated language the development team uses with the domain experts.

Really?
In a webpage scenarion, a “User” may be an Admin, a newly registered site visitor, someone who buys something in your shop, a writer of articles, an anonymous visitor.
There is not ONE user, there are many people (or machines) that play some roles in a given context.
The refinement of the UL in the domain is one of the main things we as developers have to pull out of the domain experts knowledge.
And in fact that’s not your job but the DE’s one. In a new project you don’t know which roles may exist but you ask all the experts what kind of people (and what roles) they have or expect to see in their business.

Before I knew DDD I also had, like so many others coming from a “data-based” background, a giant User class. Playing all roles and having behaviours of every possible context it could play.
But that was before DDD ;-)

> Bounded Context has nothing to do with Repositories

People in different divisions may have a completely different look at things.

A domain with only one BC has its set of repositories while another app with many BCs may have completely other ones. But both are working with the same data.

BCs are like single applications inside another. Therefore they have other needs and another view at all the things inside a domain. And for retreiving objects needed for one context we need other instruments than for another.

The accounting BC may want to look for outstanding invoices. Therefore they need a repo like ReceivableAccountsRepository.

The customer service desk may want to find registered users and their visiting history on the site.
They need a i.e. MemberRepository.

In both cases an Entity like Member could be involved but not always as an AR but as an Entity inside another AR.

ARs and almost any other “pattern” of DDD are just logical concepts, not structural ones.

Not really. The repository is also responsible for talking in aggregate roots.

Reference:

http://dddstepbystep.com/wikis/ddd/blogged-the-repository-pattern.aspx

> One time a User isn’t existing yet, but objects that play a role in a given context

User is part of the negotiated language the development team uses with the domain experts. User, in this case, is something that we, developers and domain experts, understand to mean the same thing. It’ s my job then to reflect my understanding of the domain using classes, attributes, relationships and collaboration behaviour.

> you should take a look on the concept Bounded Context

Bounded Context has nothing to do with Repositories and the example provided in this post. The team members define the context within which a model applies.

You write:
A Repository “…Is a collection of aggregate roots”

The most important, if not ONLY responsibility of a Repository: to retreive an AggregateRoot.
Most repositories do need only one method, find().
Almost any other of the often-seen methods are another context or just plain reporting.

Also perhaps you should take a look on the concept Bounded Context in DDD, then you would realize that there is almost never an Entity “User”, but objects that play a role in a given context. One time a User isn’t existing yet, or is a RegisteredMember or a Visitor. And users don’t appear out of nothing, so who calls new User()…?

Cheers!