Fix typos and correct grammar in README

README.md

@@ -2,13 +2,13 @@
 
 
 
-Domain driven design (DDD) is an approach to software design that values simplicity and modeling code as closely to the business domain as possible. This results in code that can be easily understood by the business and evolved as the needs of the business domain change.
+Domain driven design (DDD) is an approach to software design that values simplicity and modeling code as close to the business domain as possible. This results in code that can be easily understood by the business and evolved as the needs of the business domain change.
 
 By isolating domain code away from all other concerns of the system like infrastructure, security, transportation, serialization etc; the complexity of the system grows only as large as the complexity of the business or problem domain itself.
 
 If you are new to the concepts of DDD, it's highly recommended to do some background reading to grasp the motivations for this approach and to decide if it suits your application.
 
-If you have already decided to use DDD for your application, this package is part of suite of purpose-built libraries that help you and your teams write large distributed node applications that are maintainable and easy to change.
+If you have already decided to use DDD for your application, this package is part of a suite of purpose-built libraries that help you and your teams write large distributed node applications that are maintainable and easy to change.
 
 ## Installation
 
@@ -20,13 +20,13 @@ npm i @node-ts/ddd @node-ts/logger-core @node-ts/bus-core @node-ts/bus-messages
 
 ## Layers
 
-This library encourages layering code using the onion architecture approach. The main two layers that this libray provides helpers for are the domain and application layers outlined below. 
+This library encourages layering code using the onion architecture approach. The main two layers that this library provides helpers for are the domain and application layers outlined below. 
 
 ## Domain layer
 
-The domain layer sits at the centre of the system. It contains domain objects and domain services. This layer has no technical concerns like infrastructure, authentication, data access etc. The goal of the domain layer is to have a place in your application where code can be writen that models your business domains and rules in a way where those business complexities are kept separate from the rest of your application.
+The domain layer sits at the center of the system. It contains domain objects and domain services. This layer has no technical concerns like infrastructure, authentication, data access, etc. The goal of the domain layer is to have a place in your application where code can be written that models your business domains and rules in a way where those business complexities are kept separate from the rest of your application.
 
-As a result, much of the code that gets written in this layer can be read by non-technical staff meaning that greater collaboration with the domain experts and validation of expected behaviours can be performed. Code here is easily unit testable and isolated from the rest of the application. 
+As a result, much of the code that gets written in this layer can be read by non-technical staff meaning that greater collaboration with the domain experts and validation of expected behaviors can be performed. Code here is easily unit testable and isolated from the rest of the application. 
 
 The domain layer is composed of one or more **domains**. Domains are logical boundaries around broad groups of related logic. Each domain is comprised of multiple **aggregates**, which are clusters of closely related data that model a single entity in the real world. Each aggregate has a **root**, that represents the single point of access into an aggregate and hosts all the actions that can be performed.
 
@@ -36,7 +36,7 @@ A simple example is a user of a website. In this example an "account" domain is
 * `changePassword()`
 * `disable()` their account
 
-We can model that these actions have occured using bus `Events` (see [Bus Messages](https://node-ts.github.io/bus/packages/bus-messages/#event) for more details). Here are the events for those actions:
+We can model that these actions have occurred using bus `Events` (see [Bus Messages](https://node-ts.github.io/bus/packages/bus-messages/#event) for more details). Here are the events for those actions:
 
 ```typescript
 // user-registered.ts
@@ -109,7 +109,7 @@ export class UserDisabled extends Event {
 }
 ```
 
-These events above are broadcasted to the rest of your system, normally with a message bus, each time one of the actions are performed on the aggregate root. 
+These events above are broadcasted to the rest of your system, normally with a message bus, each time one of the actions is performed on the aggregate root. 
 
 The following is an example implementation of the `User` domain object:
 
@@ -185,17 +185,17 @@ export class User extends AggregateRoot implements UserProperties {
 
 This approach to modeling the business domain is well documented. It's clear what actions a user can perform, what the business rules are those actions, and what data updates as a result.
 
-Each time an action method is called on a domain objecft, an event is prepared and applied to the `when()` protected method. This method does a number of things:
+Each time an action method is called on a domain object, an event is prepared and applied to the `when()` protected method. This method does a number of things:
 
 * It adds the event into the list of new changes made to the aggregate
-* It increments the verison of the aggregate as data has now changed
+* It increments the version of the aggregate as data has now changed
 * It invokes the method named `when<EventName>` on the aggregate (eg: `whenUserRegistered`)
 
-At this point it's important to note that the aggregate has not been persisted nor the event published to the bus. This will be the responsibility of the application server that initially invoked the domain action.
+At this point, it's important to note that the aggregate has not been persisted nor the event published to the bus. This will be the responsibility of the application server that initially invoked the domain action.
 
 ### Application layer
 
-The application layer sits around the domain layer. It provides services that act as a gateway to performing actions against the domain. Broadly speaking, these services typically offer one method per command, and can retrieve domain objects from persistence, query other necessary data inputs, gather dependencies to inject and persist data back to the database.
+The application layer sits around the domain layer. It provides services that act as a gateway to performing actions against the domain. Broadly speaking, these services typically offer one method per command and can retrieve domain objects from persistence, query other necessary data inputs, gather dependencies to inject and persist data back to the database.
 
 The following `UserService` provides operations that modify the `User` domain object. Note that once an operation has been performed on the domain object, it is persisted via its write repository. This operation will store the updated object in the database as well as publishing any events to the bus.