Агрегат моделирования DDD с несколькими инвариантами и множеством полей

Как исправить совокупность дизайна, где есть правило, проверяющее, что мы можем добавить только 5 соавторов

Project AR, скорее всего, поддерживает набор соавторов и выбрасывает, когда его размер превышает 5.

есть только требования, чтобы эти поля не были пустыми (это действительно инварианты?)

Да, это могут быть простые правила, но они все же являются инвариантами.

должны содержать только данные, которые участвуют в защите инвариантов или помогают принимать бизнес-решения

Это можно сделать при моделировании AR с помощью EventSourcing, где вы материализуете только свойства, необходимые для проверки инвариантов в AR, имея при этом все данные в полном наборе событий.

реализованная как анемичная модель за пределами домена, и корень агрегации должен просто иметь метод addCollaborator, который защищает количество соавторов.

Вы всегда можете попытаться смешать CRUD-управляемую анемию с богатыми всегда валидными моделями, но решение по анемичной/богатой модели обычно соответствует заданному ограниченному контексту (BC), что означает, что у вас могут быть CRUDDy BC и BC с богатой доменной моделью, но редко обе стратегии в одном БК.

Например, возможно, Project Definition — это CRUD-управляемый BC, а Collaboration — нет. Эти BC могут не иметь никакого смысла, но это просто пример.

Кроме того, не забывайте, что тактические шаблоны DDD позволяют управлять сложностью, это не жесткие правила. Если вы обрабатываете часть вашего AR через сервисы, а другую (где больше мяса) с богатым поведением, то, возможно, это приемлемо. Тем не менее, я, вероятно, предпочел бы CRUDDy поведение на самих AR, как метод update, а не сдаваться в анемичном направлении.