Compliance Central Microservice

Question

I have multiple microservices in my solution, let's call them salary processing, cards, kyc docs, and I need to enforce compliance so that if a kyc doc has expired, I block the card, and if salary processing limit is breached, I delete the card, I'm introducing a compliance microservice to handle all compliance related matters and I've been thinking of the following designs but one is chatty and one potentially violates ddd:

Design 1:

1. The domain microservice fetches the rules from the compliance daily and caches them. (salary limit USD 5000 per calendar month, kyc is only valid when within expiry)
2. According to the rules, the microservice evaluates emits an event if there's a violation. (salary limit breached, kyc expired).
3. The compliance service receives the event and triggers another to block/ delete card, the compliance service logs only the violations.

Concerns: Domain has to evaluate compliance, is it its job to do that?

Design 2:

1. The domain microservice is agnostic of the rules.
2. The domain microservice emits what happened in it (salary loaded, kyc added/ updated).
3. The compliance service subscribes to the events and checks daily for violations, if there's a violation, it triggers events to block/ delete card, the compliance service logs all events.

Concerns: Compliance service has to store a lot of data from many domains.

What are your thoughts?

Answer 1

Design 2 is much better in terms of DDD, but it requires a more mature events model; it can work smoothly without storing data projections if you have Integration events If for some reasons you cannot introduce Integration events, then you can try using processing pipeline in your domain microservices, and plug in your Compliance microservice here by implementing ValidateCompliance step that emits the event with full context. This workaround allows to avoid storing the context data on Compliance ms side but introduce some coupling.

Answer 2

It sounds like you are centralizing all of your logic in this compliance service, and using the other services basically as data-access & storage, not embedding the logic in them. This is a good example of the Anemic domain anti-pattern. There isn't a huge problem with this, as you are trying to mix DDD and microservices, which has some serious impedance mismatch. You basically have two different drivers for your architecture that are in competition with each other. Microservices are pushing you to decompose applications into smaller bits, and DDD which is pushing you toward pulling things together so that you can leverage the object abstractions. They will likely be in conflict, and you need to draw your bounded contexts around them in the way that balances these two drivers.

Your Design 2 is basically the acknowledgement of this in that you are pulling the domain entities into the compliance context, whereas the Design 1 is inverting that, and pushing the compliance context into the domain contexts. There is no "right" answer here, it's just a decision of where to draw your bounded contexts to maximize the value of both DDD and microservices.