How to Design Aggregate Root properly-CodePudding

I'm new to DDD patterns and I don't know how to identify my aggregate root properly
There is a part of my project that deals with attachments so there are two classes Attachment and AttachmentType that form an aggregate

public class Attachment
    {
        public long Id { get; private set; }
        public string FileName { get; private set; }
        public string Location { get; private set; }
        public long AttachmentTypeId { get; private set; }
   }

public class AttachmentType
    {
        public long Id { get; private set; }
        public string Name { get; private set; }
        public bool IsActive { get; private set; }
        public bool AllowMultipleFiles { get; private set; }
  
        private readonly List<Attachment> _attachments;
        public IEnumerable<Attachment> Attachments => _attachments.AsReadOnly();
        public AttachmentType()
        {
            _attachments = new List<Attachment>();
        }
}

The relationship between the two classes is a one-to-many relationship, so every attachment type has many attachments, first I think that I could consider the AttachmentType as my aggregate root and inside it I can add methods to add/remove attachments but actually, I have only 4 attachment types in my project (Contract, Document, Deed, Others), so I found it's not logical to make it an aggregate root as I'm interested more in manipulating attachments not attachment types

Then I think that I could consider the Attachment as my aggregate root and make the attachment type an Enumeration class, but I have some properties in AttachmentType not only Id and name, these properties may need to be updated like IsActive could be set as false so I stop receive attachments with this specific attachment type, therefore I think it can't be an Enumeration class

Any suggestions?

CodePudding user response：

so I found it's not logical to make it an aggregate root as I'm interested more in manipulating attachments not attachment types

The reason for an entity to be the root of an aggregate is because when you have to link to another aggregate the other aggregate will have to know at least the id of the root, then if needed also of its sub entities.

The aggregate root "owns" its children, and the aggregate define the boundary where transactions apply.

Then I think that I could consider the Attachment as my aggregate root and make the attachment type an Enumeration class

Thinking to represent it as an Enumeration means you are thinking that the type is a Value from the Attachment perspective. When an aggregate is linked to another aggregate it will know its id, but not the details of its state (that's because is part of a different transactional boundary). The ID of the aggregate then is a Value, like your enum.

It seems to me that they should be two separate aggregates, and you just need to do a query to resolve the id into the state of the type when creating a new attachment to check all of its properties and do the validation needed.