How to implement Monitoring the right way in a SOA DDD Environment? [closed]

Question

Closed. This question is off-topic. It is not currently accepting answers.

---

Want to improve this question? Update the question so it's on-topic for Stack Overflow.

Closed 8 years ago.

Improve this question

We try to follow SOA and DDD principles in our project. We use NServicebus as messaging bus. So far we have 20+ services.

How do you guys set up monitoring (i'm not talking about technical monitoring - like is service "xyz" reachable - is the hard disk full) ?

For example

If an Order is placed and the shipping is done 5 days later but it should have been executed after 1 day ... that's an error condition.

Or another example: The shipping is done. Now we send an electronic invoice to our customer. We must archive that invoice and talk asynchronously with a third party (archiving provider) to retrieve our invoice. If that invoice is not retrieved after 5 days ... that's an error condition.

I have problems when defining HOW to model criterias on what is an error and WHERE to put these criterias.

WHERE ...

... do you set up Monitoring rules ?

Are monitoring rules part of your bounded context ? I think yes.
Are monitoring rules directly related to an entity ? I think no.
Are monitoring rules directly related to an aggregate ? I think no.

Monitoring rules are like Domain-Services that span multiple aggregates but as opposed to domain services can also span multiple bounded contexts.

Who is reponsible ?

HOW ...

... do you set up Monitoring rules in code ?

If you want to do it right its a really great deal of effort. Otherwise you could do it really cheap (make some queries here and there) but thats against SOA (the major part i'm concerned about)

Please guide me to a clear and easy to implement solution.

I'm also really excited to learn how you set this up.

Answer 1

The first thing to identify is the set of events that you're interested in. You already have some examples such as when the order shipment is late, invoice retrieval is late, etc. From the business perspective, these events have a specific meaning and specific consequences. Deciding on criteria for these events should be done in conjunction with domain experts - they should be able to say things like "when the order isn't shipped after 1 day so and so should happen".

This of course is different from implementing this event-driven architecture. One way to implement the above time triggered events is to run a continuous process which runs a query on a schedule. This query would retrieve the set of entities which satisfy the criteria for the event at the time the query is run. The resulting system would publish these time triggered events. The NServiceBus handler for those events would delegate the handling of the event to the domain layer.

Regarding the where, I agree that the definition and handling of these events will usually be tied to a specific bounded context. They could however span multiple BCs such as when an event from one BC is handled in another BC. As far as the physical placement of code, the event handler should go near the corresponding domain logic. For instance, you may have a shipping BC with a requirement to dispatch a message whenever shipping is late. In this case, the whole workflow would be contained in a single BC which could be implemented with a single VS solution.

The how of these events should be part of the infrastructure as described above. On the other hand, the handling of the events should be delegated to domain layer. For instance, you can have infrastructure that publishes OrderShippingIsLate messages with NServiceBus. In the shipping BC solution, you'd have a NServiceBus handler for this message type, which would invoke an application service which handles this message (by adding a task for a support rep, dispatching some sort of warning, etc).

Answer 2

I agree that your monitoring should be done within domain services. Read this book on the specification pattern and how to implement it. Their example is VERY close to your scenario.