Microservices architecture with Blazor and CSLA.net

[irfanyousaf08]

We are going to make microservices using Blazor and we are thinking of using CSLA.Net. I have been working on microservices with DDD and this would be my very first experience with CSLA.net. I have couple of questions

1. In DDD we raise domain events from aggregate root which are then converted to outbox messages. What is the best place to raise domain events in CSLA for integrating data with other microservices or is there any other better way to achieve that in CSLA.
2. Which Blazor template is most suitable for microservices architecture?

[rockfordlhotka]

I'll answer the second part first: Which Blazor template is most suitable for microservices architecture?

In my view, when you say "microservices architecture" this implies that you are talking about creating multiple applications that interact with each other. This is because every microservice is an app, and the Blazor client is also an app. So you are creating a system of apps that interact with each other by passing messages around between each other.

A lot of people treat a "microservice" like a captive endpoint for a client app to call. That's not service-based, that is n-tier architecture. And I really like n-tier architecture, and in fact, that is the architecture supported directly by the CSLA data portal. You'll get the most value from CSLA by using an n-tier architecture with the data portal.

Given that background, in this response I'm going to keep things simple and talk about a Blazor app that is talking to a microservice app. Because the microservice is a true microservice, we must assume it has consumers other than the Blazor app, and so can't be tailored to the Blazor app specifically. Nor can it trust the Blazor app (or any of its consumers) because that way lies madness.

I should point out that I've blogged extensively about service-based architectures, trust boundaries, and all these things. After a few years I kind of stopped, as I think I've said most of what I want to say. As a result, these posts are in my blog archive: https://lhotka.net/weblog/index.html

Also, is some discussion of this in the CSLA /docs directory in GitHub. For example:

• https://github.com/MarimerLLC/csla/blob/main/docs/ObjectsAsServiceContract.md
• https://github.com/MarimerLLC/csla/blob/main/docs/Web-API.md

You can also look at the Cloud-Native HOL content from a hands-on lab class I taught for a couple years. The repo includes extensive discussion of microservices, service-based architecture, and related concepts. Nothing CSLA-specific, but it is important to understand service-based architecture itself before introducing CSLA in any case.

So given all that...

You can use any Blazor project template to build a Blazor app and interact with microservices. In the "Cloud-Native HOL" I used Blazor server because it is simplest, but Blazor WebAssembly is also a great option.

You can use CSLA to help create the Blazor client app. You'd normally use the data portal in local mode, and have your client-side data portal operation methods inject the standard HttpClient instance(s) necessary to invoke your microservices. Though personally I strongly prefer using async messaging technologies like RabbitMQ over http, but I get that most people struggle to wrap their heads around async messaging (even though it is the right answer!).

In terms of building your microservices. Remember that each service is a standalone app, and that it must be designed to support the broadest array of current and future consumers possible. Versioning of microservice APIs is probably the hardest thing, so the better job you can do to anticipate future requirements of callers the easier life will be! And it is always important to assume the caller is giving you bad data, and/or is requesting data they shouldn't be able to see - assume malicious intent and/or incompetence on the part of consumers, just like we do with any user interface.

You can use CSLA to help create the microservice app. Because microservices are already running on servers, it is most common to use the data portal in local mode, though for security or other reasons you might use a remote data portal. It is very important to keep the shape of your domain object model (the CSLA classes) distinctly separate from the JSON contract you expose to the outside world. The last thing you want is to couple your actual domain types to the fragile interface you are committing to for external consumers, as that'll make versioning of the microservice API virtually impossible over time.

[rockfordlhotka]

I'll try to answer number 1: In DDD we raise domain events from aggregate root which are then converted to outbox messages. What is the best place to raise domain events in CSLA for integrating data with other microservices or is there any other better way to achieve that in CSLA.

When defining a microservice API contract, I think it is important to remember that there are three possible outputs from a service endpoint:

1. Success, and here's the data
2. Failure, and here's the reason why
3. Exceptional failure, and here's a 500-level result indicating server failure

Any time someone sends a message to a service, the service may or may not be able to handle the message. It is absolutely valid for a service to return a "failure" (not exception) saying that the request couldn't be handled. This might be because the input data was invalid, business rules weren't met, inventory is empty - all sorts of business logic reasons why the request can't be completed successfully.

Of course, the happy path is that the service gets a message that is valid, no business rules are violated, the business process completes, and we get to return a success message, often with data.

The final option is that something exceptional occurs. Not a business rule or validation problem, as those aren't exceptional (they are normal). But something like a timeout, database offline, network failure, etc.

Kind of like ordering food at a diner. They might make your meal. They might come back and tell you they don't have the right kind of cheese. Or the cook might have a heart attack. Success, Failure, Exception.

All this is entirely independent from CSLA - this is basic implementation of service-based systems.

When using CSLA to implement a service, the message comes into the service and (following CSLA architecture) ends up at the Interface Control layer of the app (often implemented as a controller or viewmodel).

The message data is then used to instantiate and interact with the appropriate business domain objects (built using CSLA). Those domain objects, once loaded with data from the message, can immediately tell the Interface Control code whether the object graph is valid or not, and if not then the IC layer can send a failure reply explaining the problem to the caller.

If the object graph is valid, the IC layer can use the data portal to try and save the object graph. That too can succeed or fail. If it fails, it might be because of a business rule violation in the database (a failure to report to the caller) or because the database isn't reachable (an exception).