vendredi 6 juillet 2018

DDD & Serial/USB Communication - Domain Model interacting with real devices

Situation

I am working in an app for automatic pressure/temperature/etc. measurements. I am trying to implement DDD but was wondering how I should do it.

For measuring the app communicates with different devices (DMMs, ovens, calibrators, etc) via RS232 or USB.

I already created a library "wrapping" the commands to use the devices, exposing interfaces like IPressureCalibrator, ITemperatureCalibrator,IDmm and specific implementations of the devices we own.

In my domain model I have different classes for different types of measurements,i.e. PressureCalibration, TemperatureCalibration, TemperatureDriftMeasurement which use different types of measure devices and have a different measurement-flow.

I also implement the Template Pattern for the measurement flow, i.e there is for ex. a class CalibrationCOntroller which has the pattern for a calibration and delegates some implementation to the specific controllers

Question

  • Should the measurement classes in my domain model have a controller, which also resides in my domain layer, communicates with the devices and handles the measurement flow.

    • Problem: My domain project would have a reference to another dll, the one for the measure devices.
  • Should I not use controllers and the measurement classes implement directly the template pattern with the measurement logic.

    • Problem: Same as above

Both options with me the advantage/option to make really rich models of my measurement classes, having all measurement logic implemented in the entity and being able to call sth like PressureCalibration.Run(), PressureCalibration.Stop() and having events like PressureCalibration.NewMeasureResult or Started/Completed etc..

or

  • Should I use a controller/service in my BLL layer, which has a Measurement as property (being passed in constructor) and letting it handle/know the measurement process?

    • Advantage: No references from my domain project
    • Problem: Measurement classes are not so rich - only validation and some logic and I can't do sth like Calibration.Run(), instead I would do CalibrationService.Run()

Aucun commentaire:

Enregistrer un commentaire