-1

Summary of my question in a short form: How to propagate changes of domain objects upwards without introducing application logic into them?

Following 'facts' are based on prescriptions from respected software architecture authors.

Fact 1: In layered architecture, a lower layer should never make explicit method calls upwards.

Fact 2: Objects that represent business logic should be free of any technical aspects of the software. Authors prescribe that a "Domain Layer" should isolate them from any other layers, including any upper Presentation Layers.

Fact 3: In the MVC pattern, a change propagation mechanism has to exist in the model: Any changes in objects of the model must be notified to all relevant views and controllers. The observer pattern is good for this.

Fact 4: In the observer pattern, the subject (or provider object) allows for the registration of observer objects. When the state of the subject changes, the observer objects are notified.

I have a Domain Layer (or Business Logic Layer), wish to use the MVC pattern, wish to use the observer pattern for it, and wish to respect fact 2: I do not want to introduce observer logic to the domain objects.

I'm pretty clueless about how to fit these pieces together. How can I implement a change propagation mechanism without implementing it into business logic classes?

1
  • 1
    See also my answer here about pull- vs push-based interfaces between the presentation layer and the application layer in Clean Architecture, I think it can help bring you some clarity. The Observer pattern is just a more structured version of the push based approach - provide one or more IObserver interfaces in the application layer, implement them in the presentation layer (or use events/event handlers if your language supports them, it's the same thing). Jun 20 at 20:02

2 Answers 2

3

Fact 1: True.

Fact 2: True in principle. Business logic objects should be "technology-agnostic," unless the stated purpose of a particular object is to interact with a particular technology.

Fact 3: Mostly false. If a view wants the latest version of some data, it will generally ask the controller to get it from the model. Some applications, like real-time dashboards, do require change propagation of the kind you describe, but special mechanisms like polling, events and sockets are implemented in the upper layers to make that happen. In that situation, you will need a change propagation in your model, so that the upper layers will be notified of any changes.

Fact 4: True. That's how the Observer Pattern works.

Your upper layers won't be aware of any real-time changes in the Model unless your model can provide notification endpoints that your upper layers can subscribe to. This doesn't require any technological awareness from your model; it's simply the Observer Pattern at work. Nor does it require that your model have any awareness of the layers above it, other than the fact that something may subscribe to its endpoints for notification purposes.

1
  • Just to very slightly extend your valid point about fact 3: the concept of change propagation is unrelated to MVC. You can have MVC and change propagation in the same application, but they are separate implementations and one makes no claims about the other. Fact 3 is wrongly trying to relate the two separate implementations.
    – Flater
    Jun 22 at 14:21
1

In MVC changes are initiated by Controllers. so the Controller can raise the change event rather than the model.

If the model changes by itself, then there will be some "refresh" event triggered by a Controller.

3
  • Who tells the controller to trigger that refresh event? I guess you're suggesting that this should be done in a periodical fashion.
    – reign
    Jun 20 at 19:24
  • 1
    the user or some external source
    – Ewan
    Jun 20 at 19:27
  • for refresh you can have a timer and poll, or you could push the source of the change out to consumers via push messaging of some sort
    – Ewan
    Jun 20 at 19:28

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.