Merge pull request #277 from jayserdny/patch-1

CODE RUB: typo in 2.0.2.5.0

2. Services/2. Services.md

@@ -2,7 +2,7 @@
 
 ## 2.0 Introduction
 
-Services, in general, are the containers of all the business logic in software—they are the core component of any system and the main component that makes one system different from another.
+Services, in general, are the containers of all the business logic in software—they are the core component of any system and the main component that makes one system different from another.
 
 Our main goal with services is to keep them agnostic from specific technologies or external dependencies.
 
@@ -26,7 +26,7 @@ Validations ensure that incoming or outgoing data match a particular set of rule
 
 #### 2.0.0.1 Processing
 
-Processing mainly focuses on flow control, mapping, and computation to satisfy a business need—the processing operations distinguish one service from another and, in general, one piece of software from another.
+Processing mainly focuses on flow control, mapping, and computation to satisfy a business need—the processing operations distinguish one service from another and, in general, one piece of software from another.
 
 #### 2.0.0.2 Integration
 
@@ -215,7 +215,7 @@ This principle is called a Flow-Forward - as the illustration shows:
 <br />
 
 ##### 2.0.2.5.0 For APIs
-Due to fractality, The same rule applies to methods within these services. Public APIs cannot all public APIs. Here's an example:
+Due to fractality, The same rule applies to methods within these services. Public APIs cannot call public APIs. Here's an example:
 
 ```csharp
 public async ValueTask<Student> RetrieveStudentByIdAsync(Guid studentId)
@@ -239,4 +239,4 @@ public async ValueTask<Student> ModifyStudentAsync(Student student)
 
 In the Foundation Service example above, we cannot call `RetriveStudentByIdAsync` in a `public` method from another `public` method such as `ModifyStudentAsync`. You will see that both methods call the exact same method from a lower dependency, like a `StorageBroker`, fully independent of one another.
 
-While this may seem redundant, the reason for this is that `public` APIs, contracts, or otherwise, are destined to be deprecated at some point in their lifetime. They may also be changed completely from an implementation standpoint. If a `public` API depended on another `public` API at the same level, the deprecation of one will cause a cascading effect on all others. That's a symptom of Chaotic design, which The Standard strongly prohibits.
+While this may seem redundant, the reason for this is that `public` APIs, contracts, or otherwise, are destined to be deprecated at some point in their lifetime. They may also be changed completely from an implementation standpoint. If a `public` API depended on another `public` API at the same level, the deprecation of one will cause a cascading effect on all others. That's a symptom of Chaotic design, which The Standard strongly prohibits.