Most services have the following layers and/or libraries associated with them:
- Service contracts
- Service data access
- Service host, endpoints, producers, consumers
- Service client
.NET projects are grouped into solution folders depending on the functionality:
Components
contains the projects for each piece of the system designBackplane
contains the projects related to the backplaneBFF
contains the projects related to the BFF serviceChats
contains the projects related to the Chats serviceConfig
contains the projects related to the Config serviceIdGen
contains the projects related to the ID Gen serviceMessaging
contains the projects related to the Messaging serviceUser
contains the projects related to the User service
ClientApp
contains the console client used for manual testing and the load testing appShared
contains project-specific functionality, reusable across servicesCommon
contains technology-oriented functionality, which could also be reusable in a different project
- Each service contains a customized
launchSettings.json
file which should be used in order to start it locally from the IDE - All services depend on the Config service which needs to be started prior to the others, so they obtain the configuration elements they need
- The messaging service has 2 profiles in order to simulate realistic communication between user clients connected to different instances
- Ports for each service are defined in server addresses file
A Github Actions workflow is set up to:
- Build the solution
- Verify code style
- An
.editorconfig
file describes the code style which is enforced during development - The CLI
dotnet-format
tool is used to enforce the code style during the CI workflow
- An
- Perform SonarCloud analysis
- This is the SonarCloud project link
- Build and push CecoChat containers to Docker Hub