I have a bit of a mental block when trying to model my scenario whilst practicing DDD.

The problem appears to be around 2 entities you would consider to be aggregate roots. I feel these aggregate roots would be an aggregate root in their own respective bounded context.

Essentially, I have complex rules to apply in this scenario. I've tried to simplify this with the following scenario:


The scenario would be to take a Product. This produce would be put together in a Design context with its various dimensions by the design team.

It would then be assembled on a production line in. The product would exist in a Batch.

Then once Product was assembled, it would be Quality Controlled inspected by an Inspector.

The Inspector would select a number of Products in the batch at random, and would determine if it passes the Quality Control (QC) checks. Something along the lines of is the product width between a minimum and maximum range. He would also perform a visual check of the product.

The Inspector has to be qualified to perform the various checks. Therefore he needs to have a valid Visual QC certificate which is valid to a certain date - before he would need to requalify. He would need a valid Dimension QC certificate to perform dimension checks.

You might have one Inspector doing a Visual check and another Inspector doing the dimension check. For a Product to pass QC, then Visual and Dimension checks will need to be passed. The result of the check is either pass or fail.

Applying DDD Tactical Patterns

So now we come to writing code for the Domain Model. Assuming that the DDD Strategy has been applied successfully, then I currently have:

Design Bounded Context

  • Product Batch Aggregate Root
  • Product Entity

Qualification Bounded Context

  • Inspector Aggregate Root
  • Inspection Certificate Entity

Quality Control Bounded Context

This seemingly needs to bring the concept of the Product/Product Batch and the Inspector together.

I keep running through the Vaughn Vernon's red book and countless online articles, including Udi Dahan's Many to Many.

Do we have a specific Aggregate root at play? I've tried applying Udi's theory to the scenario, so it would feel like the Inspector is the Aggregate root.

But if we need to treat the Aggregate as a whole, would that mean we need to load ALL of the child data? That would be quite an overhead - if it was all Inspections since day one and all qualifications since day one.

So to quickly mock up the model to try and add some clarity - with the primitively obsessed, not really expressive and slightly anaemic approach to quickly show some context:

public class InspectorAggregateRoot
    public Guid Id { get; private set; }

    public List<Qualification> Qualifications { get; private set; }

    public List<Inspection> Inspections { get; private set; }

    public void PerformInspection(Product product, InspectionType type, bool hasPassed)
        if (!IsInspectorQualified())
            throw new InvalidOperationException("Inspector is not qualified");

        Inspections.Add(new Inspection
            InspectionDate = DateTime.Now,
            InspectionType = type,
            Pass = hasPassed,
            ProductId = product.Id

    private bool IsInspectorQualified()
        // check inspectors qualifications
        return true;

public class Inspection
    public Guid ProductId { get; set; }

    public InspectionType InspectionType { get; set; }

    public DateTime InspectionDate { get; set; }

    public bool Pass { get; set; }

public enum InspectionType

public class Product
    public Guid Id { get; set; }
    public int Height { get; set; }
    public int Width { get; set; }
    public int Length { get; set; }

public class Qualification
    public InspectionType InspectionType { get; private set; }

    public DateTime ValidTo { get; set; }

NOTE: Yes I deliberately have omitted newing up the lists, not bothered about the anaemic part as this is quick and dirty to highlight the modelling scenario - this isn't about Value objects - yet.

Getting things right

Of course, I am not going to get things right first time. But this is me rewriting an existing system as I truly believe in DDD for complex systems. The previous one was a .NET Entity Framework solution, that essentially was driven using Entity Framework, with business logic scattered throughout the application. I horrible BBoM and some spaghetti code - and hard to unit test. I decided on applying the DDD learning to the domain I am somewhat familiar with. Its getting the Strategy right, then trying to apply the Tactical patterns that I need to get experience with.

I have already gone through countless iterations of classes. I have a nice set of value types. But its the time to glue the use cases/processes together.

So the key thing here is how to "model" the process of the Inspection of the Product.

Too many questions, but I just want to discuss approaching this and finding a best way to do things.

The questions that spring to mind are:

  • Does the aggregate approach I have demonstrated fit the scenario?
  • Would a Domain Service be a better fit?
  • Maybe Domain Events would be a better fit as I am saying something has happened?
  • Thinking performance - should aggregates load all of their children for a scenario?
  • If Product created one Bounded Context, with a lot more properties that I have put in the example, from what I understand, in the Bounded Context where it is also consumed, it is another view from that Bounded Context, although represented differently, it would be fine just to define the data that was required.

Other thoughts are:

  • An Inspector might have 100's of qualifications (ie different Inspection Types not in example)
  • There might be 1000's of products in a Batch
  • There will be lots of Batches over the lifetime of the system.

1 Answer 1


Lots of questions, but some things are clear

  • Your Inspector can't contain Inspections.

These only increase with time, so sooner or later there will be too many to load into memory. You need to move them to an aggregate root which fits with how you are going to use them. Perhaps Batch? Presumably you will fail a batch if a certain proportion of Inspections fail and there will be a natural limit to the number of Inspections per Batch.

  • Without Inspections your Inspector is effectively a domain service.

Its state remains constant while it Inspects an endless stream of Products returning Inspection results.

  • You require an aggregate check on Inspections per Product and Batch.

ie. If a product requires 2 Inspections of different types to both pass, you need to make sure that both checks have been done for each selected product

and. If a Batch needs to be failed if a certain number of products fail their inspections then you need to collect these inspected products per Batch.

It seems to me that this requires a Batch object or service of some kind


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.