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

4
votes

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:

  • Microservice "backbone" Event Store with REST API (for saving events) and Subscription API (for subscriptions ON / OFF events). (Azure SQL DB + Background checking process + Azure Service bus)
  • Many Microservices with DDD + CQRS/ES (.net Core API - CosmosDB with MongoDB)
  • Some Microservice with simple CRUD (.net Core API - SQL DB)
  • APPs to consume services

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:

  • Set the Data Visibility (admin side) to show client side
  • Set client-side settings on a specific aggregate (eg comments on / off - reviews on / off)
  • Set data not related to the domain but to client-side needs (eg SEO metadescriptions)

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:

  • Treat the ON / OFF publication simply as a PublishProduct (WRITE
    SIDE) command.
  • A ProductPublished EVENT is then generated (saved and published on bus)
  • READ SIDE recive the event and update the Materialized View.

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.

1
.netdomain-driven-designcqrsevent-sourcing
I think you need to refactor it to use CQRS (maybe Event Sourcing too). I don't know if microservices are the right solution for you. Try the simpler solution first, micros are trendy these days but really, very few apps actually need it. – MikeSW
@MikeSW The simpler solution is online from 2014. It's a monolithic software that grown fast for managing physical/online stores. The real problem now is add new features for mobile apps without slowing all processes. Vertical scale-up cost so much and it's not a good long-term solution. Some physical store become to much slow in some moments because the same app need resources for all. Why not microservices? I think it is the dream of every programmer a block system able to evolve horizontally independently and especially with the ability to allocate appropriate resources in read / write – Enrico Tirotta
You can design for micro services and implement as monolith. Going full micros will be way more complex and more expensive. The problem is not that you're using only one app/server now, the problem is the design which clearly isn't scalable nor good enough. A proper design would have allowed it to easily extract the parts that need to scale into a micros. Your sketch seems pretty ok, but despite the caption, that's not a micros. That's literally a CQRS based architecture. – MikeSW
@EnricoTirotta MikeSW's comments also make me think that you could remove all microservice related bits from your Q and it would remain the same in essence. – guillaume31

1 Answers

3
votes

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.