There's a bit of a confusion here. Repositories access aggregate roots. Aggregate roots are entities. The reason for this is separation of concerns and good layering. This doesn't make sense on small projects, but if you're on a large team you want to say, "You access a product through the Product Repository. Product is an aggregate root for a collection of entities, including the ProductCatalog object. If you want to update the ProductCatalog you must go through the ProductRepository."
In this way you have very, very clear separation on the business logic and where things get updated. You don't have some kid who is off by himself and writes this entire program that does all these complicated things to the product catalog and when it comes to integrate it to the upstream project, you're sitting there looking at it and realize it all has to be ditched. It also means when people join the team, add new features, they know where to go and how to structure the program.
But wait! Repository also refers to the persistence layer, as in the Repository Pattern. In a better world an Eric Evans' Repository and the Repository Pattern would have separate names, because they tend to overlap quite a bit. To get the repository pattern you have contrast with other ways in which data is accessed, with a service bus or an event model system. Usually when you get to this level, the Eric Evans' Repository definition goes by the way side and you start talking about a bounded context. Each bounded context is essentially its own application. You might have a sophisticated approval system for getting things into the product catalog. In your original design the product was the center piece but in this bounded context the product catalog is. You still might access product information and update product via a service bus, but you must realize that a product catalog outside the bounded context might mean something completely different.
Back to your original question. If you're accessing a repository from within an entity it means the entity is really not a business entity but probably something that should exist in a service layer. This is because entities are business object and should concern themselves with being as much like a DSL (domain specific language) as possible. Only have business information in this layer. If you're troubleshooting a performance issue, you'll know to look elsewhere since only business information should be here. If suddenly, you have application issues here, you're making it very hard to extend and maintain an application, which is really the heart of DDD: making maintainable software.
Response to Comment 1: Right, good question. So not all validation occurs in the domain layer. Sharp has an attribute "DomainSignature" that does what you want. It is persistence aware, but being an attribute keeps the domain layer clean. It ensures that you don't have a duplicate entity with, in your example the same name.
But let's talk about more complicated validation rules. Let's say you're Amazon.com. Have you ever ordered something with an expired credit card? I have, where I haven't updated the card and bought something. It accepts the order and the UI informs me that everything is peachy. About 15 minutes later, I'll get an e-mail saying there's a problem with my order, my credit card is invalid. What's happening here is that, ideally, there's some regex validation in the domain layer. Is this a correct credit card number? If yes, persist the order. However, there's additional validation at the application tasks layer, where an external service is queried to see if payment can be made on the credit card. If not, don't actually ship anything, suspend the order and wait for the customer. This should all take place in a service layer.
Don't be afraid to create validation objects at the service layer that can access repositories. Just keep it out of the domain layer.
I offer Dan North and myself (please excuse the rabbit in the headlights look, it was my first video) being interviewed by one of Eric Evans' colleagues on BDD and DDD.
Also you can have a sneak preview of a segment of the draft first chapter from a BDD book I'm writing (hopefully with Dan too):
As another effect, discussing the scenarios without any technical words, in business language, allowed the developers to pick up that language. They then carried that language into their codebase, implementing classes named after elements of the business domain, methods named after capabilities of those elements, and properties and variables named after their real-life properties and sub-elements.
This use of business terminology in code is referred to as the ubiquitous language in Eric Evans' book, "Domain Driven Design". Eric suggests that when developers start to code in a language which matches business stakeholders' terminology, conversations become fluid, without the need for developers (or analysts as a proxy) to translate back and forth from technical details to domain concepts. The code becomes more readable and easier for newcomers to understand. The value of each object in the system becomes more obvious, as well as the path by which it provides its value back to the user so that the user could provide value to the business.
JBehave introduced something new. Not only were the developers using business domain language; they were now using a language that the business understood to describe software terminology. Instead of words like test, acceptance test, act, arrange, assert, red bar and green bar, developers were talking about examples, scenarios, contexts, events, outcomes and behaviour.
JBehave, and BDD, had introduced a ubiquitous language for software development itself.
Hope this shows that BDD and DDD work very well together indeed. All feedback welcome, except on my dress sense.
Edit: You're right, the domain is pretty solid. That's why we focus on the more risky stuff like presentation and infrastructure, and talk about our understanding of the domain using scenarios. We can't get feedback on our understanding of the domain until we have something to get feedback with - but it doesn't stop us seeking the understanding anyway.
Best Answer
virtual
. This includes all reference properties and all collection properties. This is because NHibernate must be able to generate a proxy class deriving the mapped class and overriding the mapped property.IList<T>
rather thanList<T>
. This is because the collections types in the .NET Framework tend to be sealed, and NHibernate must be able to replace a default instance of the collection type with its own instance of the collection type, and NHibernate has its own internal implementations of the collection types.Iesi.Collections.Generic.ISet<T>
toSystem.Collections.Generic.IList<T>
, unless you are sure that what you want is actually a list rather than a set. This requires being conversant in the theoretical definitions of list and set and in what your domain model requires. Use a list when you know that the elements must be in some specific order.Also note that it's typically not easy to swap object-relational mapping frameworks, and in many cases it is impossible, when you have anything beyond a trivial domain model.