c # – Modeling aggregates in the following delimited context: Domain-controlled design

enter the description of the image here

I am currently developing an application in ASP.NET Core 2.2 with Domain Driven Design. What you see here is a page of Creation of Unity.

A unit is composed of competencies. A unit must have at least one competition and its name must not be blank.

A Competition must have a descriptor, at least one indicator and three tests (one of the types shown above).

Once inserted into the database, they are read by another Limited Context called evaluations.

Competencies, indicators and evidence must have identifiers (they will become entities), since they will have to be searched individually and referenced for an additional evaluation operation.

Competencies, indicators and evidence are used separately in another limited context called "Evaluation".

I am looking for some comments on how I structured these aggregates (they are simple), and if the evidence, indicators and competences are good for being entities instead of valuable objects, taking into account that for the "Context delimited by units" above) he does not necessarily see them as entities (he operates them all as part of the unit). But then, the "Limited Context of Evaluation" sees them as Entities.

I am modeling them as entities to be able to insert IDs and correct references into the data warehouse immediately (although they are a separate delimited Context, they all share the same data store).

Here are the aggregates so far (I have not finished adding the domain logic)

Public class unit
{
Public unit ID {get; private set}
Name of the public string {get; private set}
Public list Competencies {get; private set}

Public unit (UnitId ID, string name, list Competencies)
{
Validate.AssertArgumentNotEmpty (Name, "The name can not be blank");
Validate.AssertArgumentNotNull (Competencies, "The competitions can not be null");
Validate.AssertArgumentEnumarationNotEmpty (Competencies, "There must be at least one Competition");

Name = Name;
Competencies = Competencies;

}

}

Public class competition
{
Identification of Public Competition ID {obtain; set; }
Public string descriptor {get; set; }
Name of the public string {get; set; }
Public list Indicators {get; set; }
Public list Evidences {obtain; set; }

/// 
        /// When the competition is created, a new "CompetenceCreatedEvent" will be sent.
/// to be read by the message broker and take it to the other bounded context so that it can be read.
/// 
        /// 
        
        
        
        /// 
        
        
        
        /// 
        
        
        
        Public competition (Competence ID, chain name, string descriptor, list Indicators, List Evidence)
{
Validate.AssertArgumentNotEmpty (Name, "The name can not be blank");
Validate.AssertArgumentNotEmpty (descriptor, "The descriptor can not be empty or null");
Validate.AssertArgumentNotNull (Indicators, "Indicators can not be empty");
Validate.AssertArgumentNotNull (Evidence, "The evidence can not be empty");
Validate.AssertArgumentEnumarationNotEmpty (Indicators, "Indicators can not be empty");
Validate.AssertArgumentEnumarationNotEmpty (Evidence, "Evidence can not be empty");

Indicators = Indicators;
Evidence = Evidence;

CheckThatEachEvidenceTypeIsPresent ();


}


empty empty CheckThatEachEvidenceTypeIsPresent ()
{
var allEvidencesArePresent =
Evidences.Any (x => x.TypeEvidence == TypeEvidence.Knowledge) &&
Evidences.Any (x => x.TypeEvidence == TypeEvidence.Desmepeno) &&
Evidence.Any (x => x.TypeEvidence == TypeEvidence.Product);

if (! allEvidencesArePresent)
{
launch the new NotAllEvidencesArePresent ();
}

}

}

public class evidence
{
Public string ID {get; set; }
public string IstrumentId {get; set; }
public string Description {get; set; }
public TypeEvidence TypeEvidence {get; set; }

Public evidence (string ID, string ID, string ID, description of type of type evidence)
{
Validate.AssertArgumentNotEmpty (Description, "The description can not be empty");
Validate.AssertArgumentNotEmpty (instrumentId, "instrumentId can not be empty");

Id = id ?? Guid.NewGuid (). ToString ();
InstrumentId = instrumentId;
Description = Description;
TypeEvidence = TypeEvidence;
}

}



/ **
* In a true DDD scenario, in this limited context,
* Indicator would be an object of value. A domain event would be published.
* Once the indicator has been created that automatically
* Create an entity in another context limited. "The data would be duplicated."
* ** /
Public class indicator: IAggregate
{
Public Guid Key {get; private set}
public string Description {get; set; }

Public indicator (Description of the chain)
{
Validate.AssertArgumentNotEmpty (Description, "The description can not be empty");

}

}

I need help to verify the structure of the aggregates. Also, I have some concerns:

  • Rewrite what I said earlier: A unit is the added root that is to be saved (they work together in a transaction). That is why he has nested all those other aggregates. At this time, they are modeled as Entities, but I also believe that in this limited context they could potentially be modeled as Value Objects instead. Since the "Limited Evaluation Context" is what you need to have referenced. Therefore, the approach would be that once the Unit is created or modified, an Event that communicates with the other bounded context is triggered, and the other bounded context is the one that performs the … Would this be the correct approach? ? Or could I model it as an Entity from the limited context of the Unit? (I understand it's a domain question, I just do not want to add additional layers of complexity without a special reason)

  • From this question I asked, is it OK for the Event Bus to pass through a dependency on the necessary aggregates?