Please show how you would create new ToDoItems

[DerekChasse]

In this template, you aggregate ToDoItems within the ProjectAggregate. However, you also stop short of showing how you would, via API, author new ToDoItem instances. I think it would be beneficial to show how you would create these new child items of a project.

I think it would be wonderful to see:

• How you would define this in an ApiEndpoint.
• How you would incorporate this within the ProjectAggregate.
• How you would codify a Many-to-Many relationship as opposed to the One-To-Many relationship between Project and ToDoItem.
  • Is this implied by the Project <-> Contributor relationship?
  • What if the Contributor to a Project had a title within that Project? Senior Contributor vs Junior Contributor? If that were the case what ApiEndpoint would the management of that be within your example domain?

Thanks for such a great template!

[ardalis]

Adding todoitems is done in #530.
Having a many-to-many between projects and their todoitems doesn't make sense to me so I'll skip that option.
There is a sort of many-to-many relationship between Projects and Contributors through ToDoItems which I think you recognize. That's not to say ToDoItem is a join/xref table, though, so it's not a typical normalized many-to-many design.

What if the Contributor to a Project had a title within that Project? Senior Contributor vs Junior Contributor? If that were the case what ApiEndpoint would the management of that be within your example domain?

Ok so you're figuring there are N contributors assigned to M ToDoItems on 1 Project, and on that 1 Project each contributor has a specific title or role that is specific to that project only (so it's not part of the Contributor entity), right?

The initial/current design just has ContributorId on ToDoItem. You could add their title there as well, but that's not at all normalized or DRY and will easily lead to the same contributor being assigned to multiple ToDoItems with different titles. Not ideal.

Probably what I would do is add a collection of contributor titles (perhaps named ContributorAssignment or something) to the Project aggregate. The list of ContributorAssignment entities would be implemented just like the current list of ToDoItem with a public enumerable/readonly property and private list backing field. ContributorAssignment would look like this:

public class ContributorAssignment : EntityBase
{
  int ContributorId { get; private set; } // require in ctor
  int ProjectId { get; private set; } // require in ctor
  string Title { get; private set; } // require in ctor
  // perhaps metadata like DateCreated, etc.
}

This entity could live either in the Contributor aggregate or the Project aggregate (or both) but in this case I'd put it in ProjectAggregate.

Now you have the problem, what happens if you add a ToDoItem with a ContributorId that isn't in the list of assignments? This is a business rule problem so the answer depends on the rules. Maybe it's fine and the UI just lets the user know there is a new contributor with no title involved in the project. The user can fix that whenever they want. Or maybe it's critical to the invariants of a project that every contributor have a title. In that case, AddItem would do a check to ensure the ContributorId on the new ToDoItem exists in the current collection of ContributorAssignment before allowing the add to take place (otherwise throw an appropriate domain exception).

You would also have to address the case of modifying a ToDoItem to change its ContributorId if that operation is supported.

Does that help?

[DerekChasse]

It is helpful and thanks for responding.

I wasn't clear in my question, and honestly the Many-To-Many portion should probably have been a separate issue. It was not directly related to the ToDoItem type, and was scoped to be in the area between Project and Contributor.

I suppose my question just turns into "How would you model group and group membership" in this domain, which you've more or less answered.

I was confused and wondered, if we're going to give a Contributor a Title/Role within a Project, what API Endpoint would that belong to. To which I believe that you've answered that it could live in either Project or Contributor. An argument could be made for either. I was imagining a world where a new API Endpoint was created which handled this Title/Role modification, and that feels like it would be unnecessary.

Thanks,
~Derek