NET-Microservices-Architecture-for-Containerized-NET-Applications

Recommendations

Info

Therefore, in order to enforce microservice autonomy and have better resiliency, you should minimizethe use of chains of request/response communication across microservices. It’s recommended thatyou use only asynchronous interaction for inter-microservice communication, either by usingasynchronous message- and event-based communication, or by using (asynchronous) HTTP pollingindependently of the original HTTP request/response cycle.The use of asynchronous communication is explained with additional details later in this guide in thesections Asynchronous microservice integration enforces microservice’s autonomy and Asynchronousmessage-based communication.Additional resources• CAP theoremhttps://en.wikipedia.org/wiki/CAP_theorem• Eventual consistencyhttps://en.wikipedia.org/wiki/Eventual_consistency• Data Consistency Primerhttps://docs.microsoft.com/previous-versions/msp-n-p/dn589800(v=pandp.10)• Martin Fowler. CQRS (Command and Query Responsibility Segregation)https://martinfowler.com/bliki/CQRS.html• Materialized Viewhttps://docs.microsoft.com/azure/architecture/patterns/materialized-view• Charles Row. ACID vs. BASE: The Shifting pH of Database Transaction Processinghttps://www.dataversity.net/acid-vs-base-the-shifting-ph-of-database-transaction-processing/• Compensating Transactionhttps://docs.microsoft.com/azure/architecture/patterns/compensating-transaction• Udi Dahan. Service Oriented Compositionhttp://udidahan.com/2014/07/30/service-oriented-composition-with-video/Identify domain-model boundaries for eachmicroserviceThe goal when identifying model boundaries and size for each microservice isn’t to get to the mostgranular separation possible, although you should tend toward small microservices if possible.Instead, your goal should be to get to the most meaningful separation guided by your domainknowledge. The emphasis isn’t on the size, but instead on business capabilities. In addition, if there’sclear cohesion needed for a certain area of the application based on a high number of dependencies,that indicates the need for a single microservice, too. Cohesion is a way to identify how to break apartor group together microservices. Ultimately, while you gain more knowledge about the domain, youshould adapt the size of your microservice, iteratively. Finding the right size isn’t a one-shot process.38 CHAPTER 4 | Architecting container and microservice-based applications
Sam Newman, a recognized promoter of microservices and author of the book Building Microservices,highlights that you should design your microservices based on the Bounded Context (BC) pattern(part of domain-driven design), as introduced earlier. Sometimes, a BC could be composed of severalphysical services, but not vice versa.A domain model with specific domain entities applies within a concrete BC or microservice. A BCdelimits the applicability of a domain model and gives developer team members a clear and sharedunderstanding of what must be cohesive and what can be developed independently. These are thesame goals for microservices.Another tool that informs your design choice is Conway’s law, which states that an application willreflect the social boundaries of the organization that produced it. But sometimes the opposite is true -the company’s organization is formed by the software. You might need to reverse Conway’s law andbuild the boundaries the way you want the company to be organized, leaning toward businessprocess consulting.To identify bounded contexts, you can use a DDD pattern called the Context Mapping pattern. WithContext Mapping, you identify the various contexts in the application and their boundaries. It’scommon to have a different context and boundary for each small subsystem, for instance. The ContextMap is a way to define and make explicit those boundaries between domains. A BC is autonomousand includes the details of a single domain -details like the domain entities- and defines integrationcontracts with other BCs. This is similar to the definition of a microservice: it’s autonomous, itimplements certain domain capability, and it must provide interfaces. This is why Context Mappingand the Bounded Context pattern are good approaches for identifying the domain model boundariesof your microservices.When designing a large application, you’ll see how its domain model can be fragmented - a domainexpert from the catalog domain will name entities differently in the catalog and inventory domainsthan a shipping domain expert, for instance. Or the user domain entity might be different in size andnumber of attributes when dealing with a CRM expert who wants to store every detail about thecustomer than for an ordering domain expert who just needs partial data about the customer. It’s veryhard to disambiguate all domain terms across all the domains related to a large application. But themost important thing is that you shouldn’t try to unify the terms. Instead, accept the differences andrichness provided by each domain. If you try to have a unified database for the whole application,attempts at a unified vocabulary will be awkward and won’t sound right to any of the multiple domainexperts. Therefore, BCs (implemented as microservices) will help you to clarify where you can usecertain domain terms and where you’ll need to split the system and create additional BCs withdifferent domains.You’ll know that you got the right boundaries and sizes of each BC and domain model if you have fewstrong relationships between domain models, and you do not usually need to merge informationfrom multiple domain models when performing typical application operations.Perhaps the best answer to the question of how large a domain model for each microservice shouldbe is the following: it should have an autonomous BC, as isolated as possible, that enables you towork without having to constantly switch to other contexts (other microservice’s models). In Figure 4-10, you can see how multiple microservices (multiple BCs) each has their own model and how their39 CHAPTER 4 | Architecting container and microservice-based applications
Page 2 and 3: EDITION v3.1.1 - Updated to ASP.NET
Page 4 and 5: ContentsIntroduction ..............
Page 6 and 7: Communication styles ..............
Page 8 and 9: Using message brokers and services
Page 10 and 11: Additional resources ..............
Page 12 and 13: Issue security tokens from an ASP.N
Page 14 and 15: coinciding in time with the .NET Co
Page 16 and 17: similar to instantiating a process
Page 18 and 19: For VMs, there are three base layer
Page 20 and 21: (heavier), an image containing only
Page 22 and 23: The registry is like a bookshelf wh
Page 24 and 25: • You need to use Windows APIs th
Page 26 and 27: Linux or Windows Nano, you can run
Page 28 and 29: ImportantYour development machines
Page 30 and 31: Imagemcr.microsoft.com/dotnet/core/
Page 32 and 33: CHAPTER 4Architecting container and
Page 34 and 35: For example, in a typical e-commerc
Page 36 and 37: Figure 4-4. Publishing a single-con
Page 38 and 39: tmpfs mounts are basically virtual
Page 40 and 41: and decentralized data management)
Page 42 and 43: transactional purchase subsystems,
Page 44 and 45: business microservice composed of s
Page 46 and 47: purpose in another context, and mig
Page 48 and 49: Figure 4-9. A microservice can’t
Page 52 and 53: entities can be defined, depending
Page 54 and 55: The API gateway pattern versus the
Page 56 and 57: actions impact maintenance pretty b
Page 58 and 59: Figure 4-13.1. Using multiple custo
Page 60 and 61: Azure API ManagementAzure API Manag
Page 62 and 63: • If the API Gateway is developed
Page 64 and 65: A microservice-based application wi
Page 66 and 67: You might use any protocol to commu
Page 68 and 69: Figure 4-17. One-to-one real-time a
Page 70 and 71: Note that when the commands come fr
Page 72 and 73: service-bus features on top of lowe
Page 74 and 75: Microservices addressability and th
Page 76 and 77: Figure 4-21. Example of a composite
Page 78 and 79: the event order is challenging. In
Page 80 and 81: • Connect Windows computers to th
Page 82 and 83: Software platforms for container cl
Page 84 and 85: Figure 4-25. Running Kubernetes in
Page 86 and 87: This feature is based on URL prefix
Page 88 and 89: Additional resources• Visual Stud
Page 90 and 91: Step 1. Start coding and create you
Page 92 and 93: Figure 5-3. Enabling Docker Support
Page 94 and 95: FROM mcr.microsoft.com/dotnet/core/
Page 96 and 97: 1 FROM mcr.microsoft.com/dotnet/cor
Page 98 and 99: For the final optimization, it just
Page 100 and 101:
Step 4. Define your services in doc
Page 102 and 103:
Figure 5-7. Adding Docker support i
Page 104 and 105:
Using Docker CLITo run a multi-cont
Page 106 and 107:
Figure 5-14. Example of testing you
Page 108 and 109:
Additional resources• aspnet-dock
Page 110 and 111:
to consume. It should also be able
Page 112 and 113:
Figure 6-1. The eShopOnContainers r
Page 114 and 115:
deployment architecture can bring d
Page 116 and 117:
Figure 6-2. External versus interna
Page 118 and 119:
Multi-architectural pattern and pol
Page 120 and 121:
Figure 6-6. Creating an ASP.NET Cor
Page 122 and 123:
any SQL Server, such as Windows on-
Page 124 and 125:
.Take(pageSize).ToListAsync();items
Page 126 and 127:
# docker-compose.override.yml#catal
Page 128 and 129:
microservice, either data-driven mi
Page 130 and 131:
The Swashbuckle generated Swagger U
Page 132 and 133:
Figure 6-10. Swagger JSON metadataI
Page 134 and 135:
basket-api:image: eshop/basket-apie
Page 136 and 137:
Using docker-compose files to targe
Page 138 and 139:
Figure 6-12. Multiple docker-compos
Page 140 and 141:
#docker-compose.override.yml (Exten
Page 142 and 143:
docker-compose.prod.yml with differ
Page 144 and 145:
Additional resources• Building Op
Page 146 and 147:
Log.Information("Starting web host
Page 148 and 149:
}static IEnumerable<CatalogType> Ge
Page 150 and 151:
Implementing event-based communicat
Page 152 and 153:
}}OldPrice = oldPrice;The integrati
Page 154 and 155:
use the API and abstractions provid
Page 156 and 157:
Implementing a simple publish metho
Page 158 and 159:
Subscribing to eventsThe first step
Page 160 and 161:
Let’s go back to the initial issu
Page 162 and 163:
The approach illustrated in Figure
Page 164 and 165:
After the ProductPriceChangedIntegr
Page 166 and 167:
the system handles the event. Messa
Page 168 and 169:
• Chris Richardson. Event Sourcin
Page 170 and 171:
Integration testing ensures that an
Page 172 and 173:
Unit and integration test per micro
Page 174 and 175:
Since .NET Core 2.0, the framework
Page 176 and 177:
The IHostedService as defined in .N
Page 178 and 179:
public class GracePeriodManagerServ
Page 180 and 181:
• GenericHost Sample using ASP.NE
Page 182 and 183:
Figure 6-30. Sample Web API microse
Page 184 and 185:
This command only runs the catalog-
Page 186 and 187:
The important point here for Ocelot
Page 188 and 189:
Using a single Docker container ima
Page 190 and 191:
- "5203:80"volumes:- ./src/ApiGatew
Page 192 and 193:
Figure 6-38. Zoom in vision of the
Page 194 and 195:
In any case, if the app is secured
Page 196 and 197:
Using Kubernetes Ingress plus Ocelo
Page 198 and 199:
CHAPTER 7Tackle BusinessComplexity
Page 200 and 201:
DDD books• Eric Evans. Domain-Dri
Page 202 and 203:
Figure 7-2. Simplified CQRS- and DD
Page 204 and 205:
There is only one application archi
Page 206 and 207:
Dapper is an open-source project (o
Page 208 and 209:
}}}@"SELECT o.[Id] as ordernumber,o
Page 210 and 211:
https://docs.microsoft.com/archive/
Page 212 and 213:
The three layers in a DDD microserv
Page 214 and 215:
Thus, your layers or class librarie
Page 216 and 217:
has a lot of logic implemented in t
Page 218 and 219:
The Aggregate patternA domain model
Page 220 and 221:
Additional resources• Vaughn Vern
Page 222 and 223:
Figure 7-11. The order aggregate in
Page 224 and 225:
For example, following DDD patterns
Page 226 and 227:
Additional resources• Vaughn Vern
Page 228 and 229:
{if (!_requestedHashCode.HasValue)_
Page 230 and 231:
Figure 7-13. Address value object w
Page 232 and 233:
}{return false;}}return !thisValues
Page 234 and 235:
Just by looking at the domain model
Page 236 and 237:
• The identity (key) of an owned
Page 238 and 239:
public abstract class Enumeration :
Page 240 and 241:
if the validation fails. There are
Page 242 and 243:
• Martin Fowler. Replacing Throwi
Page 244 and 245:
What is a domain event?An event is
Page 246 and 247:
It is important to understand that
Page 248 and 249:
public class OrderStartedDomainEven
Page 250 and 251:
Notice that the only thing that the
Page 252 and 253:
current state of the aggregates. Th
Page 254 and 255:
{}IIdentityService identityService)
Page 256 and 257:
The Repository patternRepositories
Page 258 and 259:
public interface IOrderRepository :
Page 260 and 261:
• Eric Evans. Domain-Driven Desig
Page 262 and 263:
Note that the OrderItems property c
Page 264 and 265:
suggested by this guide have severa
Page 266 and 267:
The repository instance lifetime in
Page 268 and 269:
orderConfiguration.Property<int?>("
Page 270 and 271:
// GENERIC SPECIFICATION IMPLEMENTA
Page 272 and 273:
Use NoSQL databases as a persistenc
Page 274 and 275:
When you use a C# model to implemen
Page 276 and 277:
As shown in the following image, by
Page 278 and 279:
Figure 7-22. MongoDB API NuGet pack
Page 280 and 281:
Retrieve the dataIn C# code, like W
Page 282 and 283:
Design the microservice application
Page 284 and 285:
application’s Startup class. Your
Page 286 and 287:
Use Autofac as an IoC containerYou
Page 288 and 289:
Figure 7-24 shows that the UI app s
Page 290 and 291:
}CardTypeId = cardTypeId;CardExpira
Page 292 and 293:
As an example of a command handler
Page 294 and 295:
Figure 7-25. Using the Mediator pat
Page 296 and 297:
Additionally, async commands are on
Page 298 and 299:
var createOrderCommand = new Create
Page 300 and 301:
// CreateOrderCommandHandler.cspubl
Page 302 and 303:
public class MediatorModule : Autof
Page 304 and 305:
public class CreateOrderCommandVali
Page 306 and 307:
CHAPTER 8Implement resilientapplica
Page 308 and 309:
Figure 8-2. The impact of having an
Page 310 and 311:
certain failure scenarios faster th
Page 312 and 313:
public async Task<IActionResult> Up
Page 314 and 315:
Issues with the original HttpClient
Page 316 and 317:
Figure 8-4. Using IHttpClientFactor
Page 318 and 319:
Implement your Typed Client classes
Page 320 and 321:
Implement HTTP call retries with ex
Page 322 and 323:
complete failure of a service. In t
Page 324 and 325:
One option is to lower the allowed
Page 326 and 327:
Additional resources• Circuit Bre
Page 328 and 329:
CancellationToken cancellationToken
Page 330 and 331:
tags: new string[] { "catalogstorag
Page 332 and 333:
HealthChecksUI is easy to consume w
Page 334 and 335:
CHAPTER 9Make secure .NETMicroservi
Page 336 and 337:
public void ConfigureServices(IServ
Page 338 and 339:
TipAll details are handled by the a
Page 340 and 341:
}});options.Scope.Add("webshoppinga
Page 342 and 343:
The parameters in this usage are:
Page 344 and 345:
In this example, only users in the
Page 346 and 347:
code and making sure not to store s
Page 348 and 349:
ImportantWe recommend that you regi
Page 350:
CLI versus IDE. With Microsoft tool
show all

NET-Microservices-Architecture-for-Containerized-NET-Applications

Create successful ePaper yourself

Delete template?

Save as template?