What we are going to build - Azure Tutorial

- [Instructor] Let's describe the things that we're going to build. To get the most out of this training course, I've already created some code to speed up the learning experience and also be able to balance the course length. We have three microservice projects built with asp.net core. These micro-services are pet, rescue, and hospital. In chapter one, we'll implement code to communicate between microservices in a loosely coupled fashion. For this we'll use Azure Service Bus, topics, and subscriptions. The pet microservice stores its data in a SQL server database by using the entity framework core. It publishes some event messages to Azure Service Bus that are a synchronously brokered to the rescue and hospital microservices. Just like the pet microservice, both rescue and hospital use a SQL server database and the entity framework core to process the incoming events data. In chapter two, the search and rescue pattern we'll expand the current code base to add some commands and value objects, and we'll create a new rescue query microservice. In chapter three, event sourcing and microservices, we're going to sort individual events of the patient aggregate in Azure Cosmos DB. Then we're going to create a new Azure function that automatically obtains the created items, in other words, the patient events. We're going to implement some code to project the current state of the patient entity to a SQL server database. Finally, we'll add a new patient query controller that takes advantage of the projected data. In our micro-services system, it'll be ineffective for a client application to communicate to each service directly. That's why in chapter four, API gateway, we'll build a new API gateway service that could sit it in the middle of the client applications and the rest of microservices. Last but not least, we're going to add some cross-cutting concerns in our microservices, such as versioning and centralized logging. There are countless ways of designing software and actually there's no such thing as a perfect software architecture. Regardless, the code of this course follow some principles. The core implementation is inspired by domain driven design principles and tools such as bounded contexts, aggregates, entities, value objects, and domain events. Also, the code implementation is pragmatic. That is, we're going to focus on the topics rather than on the details. For example, when handling commands, we're going to directly use an application service object and its methods from the controllers. This leads me to the following principle. We're not going to over-engineer the code. In real world scenarios with microservices, sometimes it's okay not to follow some principles such as dry We'll try to avoid accidental complexity at all costs and avoid adding extra layers of indirection. We'll try to reduce the usage of third-party frameworks or libraries. While there are numerous frameworks that we could use, I believe they could distract us from the things that really matter. Finally, one of our main goals will be to implement truly autonomous services. That's precisely one of the reasons for using microservices in the first place. Let's dive deeper into each microservice. The pet microservice uses a pen entity where all the domain logging gets implemented. This microservice is able to receive commands to perform some actions and processes in the pet domain model. And it also exposes a query. We can consider the pet microservice as a core microservice in this course. This is because it publishes the required events for the other microservices to be useful. As I've already mentioned, it uses the pet database that is a SQL server database. The rescue microservice uses the rescued animal and adopter behavior reach entities. In addition, this microservice exposes some endpoints capable of receiving commands. Furthermore, it handles one of the integration events that the pet microservice publishes. The database of this microservice is rescue and it's also a SQL server database. The goal of the rescue query microservice is to expose an endpoint that returns data from the rescue database. As you can see both, rescue and rescue query micro-services use the same database. Don't worry. This is okay when using the CQRS pattern. Again, pragmatism is the name of the game. The hospital microservice uses the patient and procedure entities. In fact, patient is an aggregate that internally uses the procedure entity. The patient aggregate tracks all the domain events that happen. This is an essential trait of this aggregate, since it'll be the basis for implementing the events sourcing pattern. Similar to the other microservices, hospital receives commands, exposes a query, and handles an event. Event storage for this microservice is an Azure Cosmos DB database with a single container named patients. The hospital projector function is triggered automatically by the Azure Cosmos DB change field. This function rehydrates this state for a given patient, and then it stores the more current state in the hospital database in SQL server. That's precisely the patient query data source. Lastly, let's discuss what's out of scope. In the code, we're not going to deal with transactions when processing data and triggering events. We're not going to deal with deployment tasks. However, that could be a straightforward task, mostly if you were to use Docker containers for your microservices. Finally, we're also not going to deal with security topics such as authentication or authorization. Well, that sums up what we're going to build. This is going to be fun, isn't it?