You’re assuming that all collections use a store-by-reference model in which only references to the objects are stored. There’s nothing that says you cannot use a store-by-value model in which a copy of the object data is recorded. In such a case, simply use get() and set() methods with the latter adding or overwriting an object as appropriate.

The common approach seems to be you find the object you want first and set the new values on it.

Customer customer = customerRepository.find(id);
customer.Name = newName;

The new name is later persisted by the Unit of Work.

This bothers me because I have to do a get before I can update something. I should be able to just add an Update to the UofW (i.e NHibernate’s Session.Update); but where can I do that if not in a Repository?

How do you handle updates?

Repositories are part of the domain, so I put the interfaces in MyApp.Domain. Services are part of the domain, so I put at least domain services in MyApp.Domain.

for example if Enity & Domain Services are not use Repositories – I want do it physically( put in separate assembly), not logically.

So, let’s me place repositories and Hibernate mapping in separate assembly( e.q. MyApp.Data, as in [SharpArchitectecture(http://code.google.com/p/sharp-architecture/) )

Where must I place repository interfaces? 1. MyApp.Data 2. MyApp.Model 3. Another, separate aseembly?

Fair enough. I think that’s just semantics of the meaning of the word, not a representation of the concept. It’s clear that not every entity deserves its own Repository, namely child entities in an Aggregate. That was the whole point of Colin’s comment.

With all due respect, I don’t think you’re quite grasping the concept of an aggregate. According to both a standard English dictionary and Evans’ book, an aggregate is a combination of separate elements into a single unit. By that definition, a standalone element cannot be an aggregate.

As for the delineation of boundaries, standalone objects already do this. The creation of an additional border is only necessary when more than one object is involved. This allows enforcement of the group’s internal cohesion. Standalone objects enforce their own cohesion.

A standalone Entity is its own Aggregate, and Root. The idea is that you have Entities, but Aggregates are how you draw boundaries around them. Every Entity must belong to an Aggregate, and every Aggregate has a root. That’s how you arrive at the one Repository per Aggregate idea.

I’m a bit confused as to from where exactly the idea comes that “only aggregate roots should have repositories.” I have Evans’ book open in front of me as I type this, and I’ll be damned if I can see anywhere he states this. It also makes no logical sense.

The purpose of a repository, as per Evans, is to provide a means of obtaining references to existing domain objects via global accessibility (as opposed to traversal from another object). Suppose that a given design contains no aggregates, but only simple entities without any embedded value objects. By your statement, no repositories should exist. How then is one to obtain references to the existing entities?

Thanks for the pointers regarding transactions and repositories. I always liked the idea of transaction demarkation using attributes , which is now possible with Castle. E.g

[Transaction(Mode.Requires)]

@Colin

I’ve always used Object Mother for setting up reference data in tests. The only thing is, if you have a lot of it, then you’ll experience speed problems.

In the case of a huge list of countries, you could always have an Object Mother method that only sets up 1 or 2 countries, which might be enough to satisfy the test case. Also, don’t set it up in test fixtures that don’t need it.

So far the repositories have just used HQL/Linq or, where necessary, SQL.

Does sound like you’re going for something very similiar, be very interested to hear you get on.

I’d also be interested to hear what others are doing regarding clients always talkin to app services. I’ve tended let the apps talk to the domain directly where applicable but I’d be interested in hearing how you and Jimmy approach this.