Applying DDD principles with C# repositories
I have a relatively simple domain model, as show by the attached diagram and simple domain logic. I would like to maintain this logic within my domain objects as defined by DDD.
Each domain object is defined as an abstract class which only contains its respective members and domain logic. Concrete implementations of these classes are be returned by the repositories, supplied to the service (with DI).
What I am having trouble with is understanding how to deal with the situation that I need to create a new entity. For example the domain logic dictates:
An account can be added to a Group (creating a Member entity).
When an account is added to a group, the new Member entity's Value property must be set to the total number of members that are already in the Group.
Every other member of the Group must have their value incremented by 1.
I could implement this as a Member AddMember(Account account) method on Group. However this method will somehow need to instantiate a new Member to add to the Group's Members collection.
As the domain object's have no references to the layers further up in the application, and the domain objects them self's are abstract, I'm unsure how to go about constructing the new instance of Member.
I have considered the possibility of defining an abstract protected Member CreateMember() method on the Group object that concrete implementations can implement but this seems messy to me and concerns me that I may be misunderstanding something more fundamental.
While trying to stay true to DDD principles, how would I go about implementing this model?
You probably want to create a MemberFactory (as a Domain Service) that has the responsibility of creating new Member objects. See this answer for a great example.
I think the fundamental issue here is the fact that your domain objects are abstract. Domain objects should almost always be concrete classes (though there are a few exceptions) that implement all the necessary domain logic.
A repository is simply an interface to an external data source (such as a database) and shouldn't affect how your domain works. By having the repository return the actual implementation of your objects, you are coupling domain logic with the repository.
You should rethink your design so that your entities are concrete classes. Together, your domain objects should implement all the domain logic without regard to external services / repositories.