0

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:

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.

  1. 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.

  1. 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

Alexey Zimarev
  • 17,944
  • 2
  • 55
  • 83
Andez
  • 5,588
  • 20
  • 75
  • 116
  • 1
    These are distinct concerns. I think you should ask separate questions for them. – guillaume31 Apr 04 '16 at 11:17
  • 3
    Bounded Context / Aggregate design is usually the result of analyzing real life constraints and modelling with domain experts. Made-up domains are hard to work with since you don't have these strong business and technical constraints to guide you. With all those question marks which you have no real world facts to decide on, there's a high risk of finding yourself caught in analysis paralysis. – guillaume31 Apr 04 '16 at 11:24
  • Agreed. But in order to keep an example simple on here, I have put together the concept with what I thought would be enough detail to hopefully get some idea of where to start. I have constraints on who is allowed to perform a build based on some business rules. This data is captured and entered. The domain model would prevent entering a build where a builder is not qualified. Maybe I did put too much in, but if I can rephrase the question, I will - it would be along the lines of to get some code together on the diagram. I guess identifying bounded contexts would come after. Any thoughts? – Andez Apr 05 '16 at 19:33

1 Answers1

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.

aryeh
  • 959
  • 6
  • 16
  • That's the root I took. I am currently working on the problem domain. I will put answer when I get one hopefully, but for now I focused on purely the domain functionality - and it surprised me how things could fit together naturally. The important part at the minute was to totally disregard what I had in the Data Model - which the conceptual model was based on. – Andez Apr 17 '16 at 20:20
  • I have started purely on the Build Product part of the model which seems to fit together nicely. Next step is the Inspection/Quality Control part. Not thought about this too much so far, but my gut feel is that it will be a different model - not in the same model. But won't know for sure until I start writing this code. – Andez Apr 17 '16 at 20:21