Reviewing the Implementation Details
Explore the detailed implementation of a scalable event-driven application using .NET 7, including solution structure, identity management, CloudEvents schema, local debugging, and leveraging new framework features like minimal APIs and OpenTelemetry for observability.
After looking at the patterns that will support the business use cases for the application, we can now move on to more specific implementation details. While some of the implementation constructs used in this solution will seem familiar, there are some technical details that might be new to us. We’ll be exploring several topics in this section, which are intended to prepare us for the journey ahead.
The Visual Studio solution topology
The solutions within the source folder are divided domain wise, with a separate solution for each. Additionally, there’s a solution for core platform needs, such as marker interfaces to identify value objects, entities, aggregates, and other objects. The intent is to allow for each of the services to be run as an independent solution, which are eventually moved into their own repositories if so desired. Here are the src directory files:
Bud1 ( o d elg1Sco @ � @ � @ � @ ( . v s c o d elg1Scomp . v s c o d emoDDblob =��A . v s c o d emodDblob =��A . v s c o d eph1Scomp M T A E D A . C o r elg1Scomp � M T A E D A . C o r emoDDblob 2p�=��A M T A E D A . C o r emodDblob 2p�=��A M T A E D A . C o r eph1Scomp p M T A E D A . E q u i p m e n tlg1Scomp 4� M T A E D A . E q u i p m e n tmoDDblob gj�=��A M T A E D A . E q u i p m e n tmodDblob gj�=��A M T A E D A . E q u i p m e n tph1Scomp � M T A E D A . I d e n t i f i c a t i o nlg1Scomp b� M T A E D A . I d e n t i f i c a t i o nmoDDblob ۆ�=��A M T A E D A . I d e n t i f i c a t i o nmodDblob ۆ�=��A M T A E D A . I d e n t i f i c a t i o nph1Scomp � M T A E D A . M a i n t e n a n c elg1Scomp �� M T A E D A . M a i n t e n a n c emoDDblob ��=��A M T A E D A . M a i n t e n a n c emodDblob ��=��A M T A E D A . M a i n t e n a n c eph1Scomp � M T A E D A . N o t i f i c a t i o nlg1Scomp TL M T A E D A . N o t i f i c a t i o nmoDDblob ���=��A M T A E D A . N o t i f i c a t i o nmodDblob ���=��A M T A E D A . N o t i f i c a t i o nph1Scomp � M T A E D A . P a s s e n g e rlg1Scomp MO M T A E D A . P a s s e n g e rmoDDblob � �=��A M T A E D A . P a s s e n g e rmodDblob � �=��A M T A E D A . P a s s e n g e rph1Scomp p M T A E D A . S c h e d u l i n glg1Scomp e� M T A E D A . S c h e d u l i n gmoDDblob � �=��A M T A E D A . S c h e d u l i n gmodDblob � �=��A M T A E D A . S c h e d u l i n gph1Scomp @ M T A E D A . S t a t i o nlg1Scomp Sl M T A E D A . S t a t i o nmoDDblob a��=��A M T A E D A . S t a t i o nmodDblob a��=��A M T A E D A . S t a t i o nph1Scomp � t e r r a f o r mlg1Scomp � t e r r a f o r mmoDDblob =��A t e r r a f o r mmodDblob =��A t e r r a f o r mph1Scomp ` E DSDB ` � ( 0 @ � @ � @ M T A E D A . P a s s e n g e rlg1Scomp MO M T A E D A . P a s s e n g e rmoDDblob � �=��A M T A E D A . P a s s e n g e rmodDblob � �=��A M T A E D A . P a s s e n g e rph1Scomp p M T A E D A . S c h e d u l i n glg1Scomp e� M T A E D A . S c h e d u l i n gmoDDblob � �=��A M T A E D A . S c h e d u l i n gmodDblob � �=��A M T A E D A . S c h e d u l i n gph1Scomp @ M T A E D A . S t a t i o nlg1Scomp Sl M T A E D A . S t a t i o nmoDDblob a��=��A M T A E D A . S t a t i o nmodDblob a��=��A M T A E D A . S t a t i o nph1Scomp � t e r r a f o r mlg1Scomp � t e r r a f o r mmoDDblob =��A t e r r a f o r mmodDblob =��A t e r r a
Each domain will have API services that can be communicated with. These projects in Visual Studio are not overly complex or even far from the general project template that’s created when we create a new .NET Core API app. There are separate project types for queries, which read data, and commands, which affect data. Each domain will have a domain library, an infrastructure library, and test projects where applicable. Also, each domain will have a persistent consumer, in the form of an executable, that will run to enable listening for domain messages and handle those messages accordingly.
Solution folders will also be present to house Docker files, Docker Compose files, and any relevant Infrastructure-as-Code (IaC) or Configuration-as-Code (CaC) required to deploy the necessary components. Eventually, this will also be the location of the YAML file that defines the build and release pipeline.
Note: The namespaces in each solution all start with a common acronym: MTAEDA. This ...