DDD Conceptual Model to Domain Model with Aggregate Roots

Question

I'm trying to model my domain based on an existing C# WinForm based system I did to improve my learning on DDD, so I've put together a hypothetical conceptual model to simplify matters. The system itself did not have a typical business domain with lots of logic mixed in to Entity Framework objects which were used through all aspects of the system. I feel it was a Big Ball Of Mud (BBOM).

I have worked around some DDD concepts at work, but I want to improve my overall understanding. I read through Evans' Blue Book "Domain-driven Design: Tackling Complexity in the Heart of Software" and Scott Millets "Patterns, Principles and Practices of Domain-Driven Design". As well as watching countless videos on the subject, and also Vaughn Vernon's articles. I feel having done more data driven development over the years it's taking an age for this to sink in.

So the hypothetical system is a strict quality control system for building products which loosely follows a system I did.

Here is the conceptual model:

Now I see 3 parts to this - not necessarily bounded contexts but I am struggling to identify where these bounded contexts lie.

There are 3 parts of the business process:

1. Defining Products

For this the "user" will input the various product information including the name. As part of this they define what thickness the product should be and what material it is made of. They will also define what process the Builder needs to use to build the product. They also define whether a Visual Inspection and a Quality Inspection is required.

2. Build Product

As part of the process a "builder" will assemble the product. But this is solely restricted as to a builder's qualifications. A Builder is qualified against a Process which is based on a Thickness Range and Material, so the business rule would only allow a Builder to be selected if they are qualified for the Product Thickness being between the Process Thickness Range and Material.

3. Inspection

Once the Product has been built, it can be inspected. As part of this, depending upon whether the Visual or Quality Inspection types are required, an up-to-date qualified "inspector" will be able to inspect the Product. They will either Pass or Fail the inspection.

As part of the flow through these processes, the status of the product will be updated. This will be:

• Not Assembled
• Assembled
• Partially Inspected (one of the two inspections has been done)
• Passed Inspection (all inspections done)
• Failed Inspection (any inspections failed)

The following is some information about the system outside of the domain that needs some thought bearing about:

• The system is designed to be a multi-user where Inspections can be entered at the same time
• It is possible that data was entered incorrectly on the Product which could be corrected which could invalidate any entered build and inspection data
• The entered data is then used in various Reports.

So I need some ideas as to:

1. Where my Bounded Contexts lie.

2. How to model my Aggregate roots - what data should be the root and what entities/value objects I should include.

   Do I only include data of the domain objects I need within a bounded context - ie do not hydrate the domain objects fully.

3. How to implement something to calculate statuses through the varying parts of the process.

4. How to handle possibilities where data can be entered incorrectly to keep the domain data correct.

I'm not interested in any repository implementation, just the pure domain concepts, although the question what should we persist for each bounded context would help me.

I have my concerns are having multiple users entering data to keep the data consistent around the Product Status

Answer 1

One thing you should consider, is disregarding DDD until you have a useful initial working domain model, especially as your domain is tiny. Forget about aggregates and bounded contexts. Like many, your viewing these "building blocks" of DDD as the "essential parts" of a working application. They aren't ... your domain model is.

Consider that by default, you do not need to have bounded contexts, aggregates, domain events, services, repositories or factories. These are all concepts to be applied only where necessary.

Do you know how to turn a domain model into a working application? Let me know if I can help.