aggregateroot

I need help with finding my aggregate root and boundary. I have 3 Entities: Plan, PlannedRole and PlannedTraining. Each Plan can include many PlannedRoles and PlannedTrainings. Solution 1: At first I thought Plan is the aggregate root because PlannedRole and PlannedTraining do not make sense out of the context of a Plan. They are always within a plan. Also, we have a business rule that says each Plan can have a maximum of 3 PlannedRoles and 5 PlannedTrainings. So I thought by nominating the Plan as the aggregate root, I can enforce this invariant. However, we have a Search page where the user

In Domain Driven Design, one of the defining characteristic of an Entity is that it has an identity. Problem: I am not able to provide a unique identity to Entities on instance creation. This identity is only provided by the repository once the entity is persisted (this value is provided from the underlying database). I cannot begin to use Guid values at this point. The existing data is stored with int primary key values and I cannot generate a unique int on instantiation. My solution: Each Entity has an identity value The identity is only set to a real identity once persisted (provided by the

Example: Your database has a SQL view named "CustomerOrdersOnHold". This view returns a filtered mix of specific customer and order data fields. You need to fetch data from this view in your application. How does access to such a view fit into the repository pattern? Would you create a "CustomerOrdersOnHoldRepository"? Is a read-only view such as this considered an aggregate root? Mohamed Abed I would prefer separating the read repository, preferably even change its name to Finder or Reader, the repository is meant for Domain usage not for querying read-only data, you can refer to this article

As part of my domain model, lets say I have a WorkItem object. The WorkItem object has several relationships to lookup values such as: WorkItemType : UserStory Bug Enhancement Priority : High Medium Low And there could possibly be more, such as Status , Severity , etc... DDD states that if something exists within an aggregate root that you shouldn't attempt to access it outside of the aggregate root. So if I want to be able to add new WorkItemTypes like Task, or new Priorities like Critical, do those lookup values need to be aggregate roots with their own repositories? This seems a little

I'm currently working a lot with DDD, and I'm facing a problem when loading/operating on aggregate roots from other aggregate roots. For each aggregate root in my model, I also have a repository. The repository is responsible for handling persistence operations for the root. Let's say that I have two aggregate roots, with some members (entities and value objects). AggregateRoot1 and AggregateRoot2. AggregateRoot1 has an entity member which references AggregateRoot2. When I load AggregateRoot1, should I load AggregateRoot2 as well? Should the repository for AggregateRoot2 be responsible for