0

My domain is a pipeline for processing data and sending it off to another place afterwards. It's defined by these rules:

  • Data is divided into Signals, which have some identifiers (name, category, type) which never change. The data itself for a Signal changes over time.
  • The pipeline is separated into discrete steps for whom the user can select which Signals are processed there. For example a processing step could just +1 whatever number Signal the user has selected.
  • The output of a processing step is always a new Signal, so the original inputs keep existing.
  • The output of a processing step can also be the input of another -> chaining is possible.
  • A processing step can have multiple in- and outputs.
  • The user can add/remove processing steps at whim.
    • Should a removal mean another processing step loses its input, that step should issue a warning and not do any work (not modeled here of brevity).
  • Circles in the resulting directed graph shall not be possible (also ignored for brevity)

I think my domain model should look like this: domain model

The idea is that a ProcessingStep has InputSlots and produces Signals. An InputSlot can be connected to another ProcessingStep using a Connection.

The "start of the chain" is a ProcessingStep which has no inputs, only outputs. Or even multiple of these.

Following the resulting graph of interconnected ProcessingSteps and doing the calculation with it will be done by an application service. This application service is also responsible for forwarding the data later on.

This model means that Connection holds the value object Signal of another AR, since it needs to be known which Signal of the source ProcessingStep is used. Is this problematic in DDD? If yes, is this a symptom of a bigger problem?

1 Answer 1

2

No - as long as the value object is immutable widely shared references to it are not a problem. This is because taking a reference to an immutable object is effectively the same as taking a copy of it.

2
  • Thanks, now that you've written it makes absolut sense. Completely forgot that the value objects are immutable of course.
    – wlfbck
    May 10 at 10:06
  • 2
    Thanks. I actually noticed in the Evans Domain Driven Design book he says that value objects should almost always be immutable but very occasionally it's OK to make them mutable and in the latter case they shouldn't be shared widely. But I think the terminology has settled on VOs always being immutable. If it's mutable it's just an object.
    – bdsl
    May 10 at 11:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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