CODEWITHSUNDEEP
.netdomain-driven-designcqrsevent-sourcing
Enrico Tirotta
Enrico Tirotta

Reputation: 323

Domain-Driven Design: Microservice (CQRS+ES), Client Visibility and Metadata

If the questions or statements I make are incorrect please forgive me, I am new in the development of Microservices. I'm studying to change the business software related to my business. Now it is a necessity linked to the limits reached by the current software that I have written in recent years.

DEV CONTEXT:

I sell local food products in many European countries. I have 2 physical stores, 1 company online shopping to which the ebay and amazon stores are "connected". The program I wrote in these years is a web solution (.NET MVC / API with EF6 on SQL DB) composed of 2 web app .NET / AngujarJS (public CLIENT + private ADMIN) and various c # libraries to separate: data access, data model and shared utilities. Everything is managed centrally by this software.

ARCHITECTURE LIMITS:

The need for a new architecture arose from the project to open new physical stores and the introduction of mobile apps. Managing everything with a single source of reading and writing (I try to use cache redis everywhere) has now become too limiting, slow and expensive. Just as it is limiting to expand the software with new functions in a more "agile" way. I am therefore studying to completely rewrite the software based on Microservices.

NEW ARCHITECTURE WITH MICROSERVICES:

The structure that grown in my mind:

MY PERPLEXITIES:

The transition from thinking the software in Data-Centric mode (EF data model + CRUD op) to software that captures the "behaviors" (DDD model + ES / CQRS) is certainly the most exciting and difficult part in starting this path . My perplexities on how to act arise in the following cases:

Let's take the example of a PRODUCT to sell. Before being able to show it to customers, all data must be entered and checked. In the past, I inserted in the database data model some simple bool ON_OFF_Visibility, it was enough then to modify the boolean ADMIN side, so the CLIENT side was able to see or not the product. Now with a DDD approach it is not correct to dirty the model of an aggregate with similar data. I would therefore like to act as follows:

In other words, the View Model is updated, the product becomes visible after a request on the admin side.

MSA publish example

Is this a correct way to act? is it correct to want to simply capture the user's behavior, save it as an event and change the data related to the View Models? Can it be considered correct to make the same reasoning also for data related to the SEO metadescriptions and metadata that only affect the client side and that have nothing to do with the business model?

Thanks for your time.

Upvotes: 4

Views: 1213

Answers (1)

VoiceOfUnreason
VoiceOfUnreason

Reputation: 57249

Your basic sketch is correct.

Queries sent to the read side are managed by grabbing the latest available representation out of your cache (the mongo db instance, in your drawing), computing from that representation the correct answer to the query.

The cache is updated by a background process, which transforms events into the representations stored in the cache.

You add new events into the system by sending messages to the domain model that lives in the write side. The writes themselves are typically synchronous, which is to say that when handling a message, you don't normally signal that the message is done/handled until you've gotten an acknowledgement back that the events this message produces have been successfully stored.

Upvotes: 3

Related Questions