Validation in a simple DDD example

Question

I'm doing a simple project that represents a CI Pipeline in a low scale. So I'm trying to model "the best way possible" to practice DDD.

Basically I have the following information:

• PipelineSettings (A configuration file that shows me the steps the pipeline will have)
• PipelineSteps (A collection of classes implementing an interface that will execute part of the job)

I started with a class called RunPipeline that work as a command/application service.

RunPipeline has two repositories IPipelineSettingsRepository & IPipelineStepsRepository and I was thinking in creating a Pipeline object that will be a domain object inside this command.

So the code would be something like this:

public class RunPipeline {

    private readonly IPipelineSettingsRepository pipelineSettingsRepository;
    private readonly IPipelineJobsRepository pipelineJobsRepository;

    public RunPipeline(
        IPipelineSettingsRepository pipelineSettingsRepository,
        IPipelineJobsRepository pipelineJobsRepository) {

        this.pipelineSettingsRepository = pipelineSettingsRepository;
        this.pipelineJobsRepository = pipelineJobsRepository;
    }

    public async Task Run(BuildOrder buildOrder) {
        var pipelineSettings = pipelineSettingsRepository.GetAll();
        var pipelineSteps = pipelineJobsRepository.GetAll();
        var pipeline = new Pipeline(pipelineSettings, pipelineSteps);

        await pipeline.Run(buildOrder);
    }

}

But I need to perform a validation that is that every pipeline setting is backed by a pipeline step, because if not I will try to execute a step that will not be able to be executed and it will fail.

So I was thinking in a few options:

• Have a Pipeline factory that has a validation service injected, verifies and then returns the Pipeline object
• Have a domain service that creates a Steps object containing inside a collection of Steps containing a PipelineSetting(config) for that Step and a PipelineStep(execution) and inject that to the Pipeline object.
• To inject or create internally a validator in the Pipeline object.
• To validate this in the RunPipeline command (I don't think this would be good cause I could create a pipeline with an incorrect state)
• To create a Validate method in Pipeline object and pass a IPipelineValidation implementation and pass it from RunPipeline command.

I'm thinking that Pipeline is the core of the app, and should execute concrete behaviours since is what it's solving a specific problem for this business.

What do you think?

Answer 1

[..] Pipeline is the core of the app, and should execute concrete behaviours [..]

In object-orientation every object is supposed to execute behavior. Combined with DDD, that behavior should be specifically business-related behavior.

In this context, I think there are too many abstractions here, some only tangentially relevant to the domain. Specifically I think PipelineSettings is a technical thing. What behavior does it have in your model? PipelineStep is good, although sounds a bit technical, I would perhaps call it Task (as some CI systems do). I suspect Pipeline could be a Task, if it has the same exposed behavior (i.e. run it).

The RunPipeline sounds and looks like a procedure. It gets data from somewhere and does something with someone else's data. This should belong to a proper object.

Overall I suspect (and I don't know your specifics of course) this could be achieved with less number of abstractions (i.e. simpler), and less procedurally (i.e. more maintainably).