I need to tackle this problem : we have to model some services aimed to handle all our customer registration process : - this include registration of the personal data (name,surname,email whith a scan of his ID card...) - contact information : with email and address (with proof of domicile)

The customer account is created as soon as the email address his confirmed (via a link sent to his email address) and the account is effective as soon as all the scanned data are verified by a backoffice user.

The customer have access to his information and could for example change his name by providing a proof (a copy of his new ID card). If the backoffice user validate the scanned Id card , the customer name change become effective. A variation could be that the change is effective and could be roolback later in case of rejection in the validation process of the scanned document.

For the microservices part, our architecture is like this : - We have designed a customer microservice - As we have a lot of (scanned) document to validate : we have created a proofValidation microservice. All our integration are point to point, as we are not using any message queue (some of us find it's complicate to manage and we could do more or less the same think with a db).

But I am not sure how to expose those service to a UI : for example to handle the name update : should I create a hight level service responsible to handle the process (some kind of orchestrator) and roll it back if there is a rejection int the validation of the scanned document ? If this hight level service need persistence for rollback isn't it ridiculous to have only one or two tables ?

Another possibility is to handle all the use cases in the customer microservice : but in this case this service could evolve more often than not when the requirement on the registration process are changed...

  • You'll want to look into versioning your data. There's a number of different approaches, but fundamentally, we have to deal with slow changing data -- data that occasionally changes, where we need to be able to have history so we don't invalidate other information, or so we can rollback. For example, let's say we change a customer's address, probably prior orders should not reflect that change. – Erik Eidt Jan 17 at 16:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.