GITBOOK-3: Some structure fixes

asynchronous-api-guidelines/core-asynchronous-principles/messages/README.md

@@ -0,0 +1,7 @@
+# Messages
+
+A message in general is a piece of information that travels from an emitter to a receiver. There are different types of messages:
+
+* Commands
+* Queries
+* Events

asynchronous-api-guidelines/core-asynchronous-principles/messages/commands.md

@@ -0,0 +1,8 @@
+# Commands
+
+A command is a special type of message which represents just an action, something that will change the state of a given system.
+
+* There is a clear expectation about a state change that needs to take place in the future
+* When returning a response indicate completion
+* Optionally they can include a result in the response
+* Very common to see them in orchestration components

asynchronous-api-guidelines/core-asynchronous-principles/messages/d_basic_concepts_events/README.md

@@ -0,0 +1,18 @@
+# Events
+
+An event is both a fact and a notification, something that already happened in the real world.
+
+* No expectation on any future action
+* Includes information about a status change that just happened
+* Travels in one direction and it never expects a response (fire and forget)
+* Very useful when...
+  * Loose coupling is important
+  * When the same piece of information is used by several services
+  * When data needs to be replicated across application
+
+A message in general is any interaction between an emitter and a receiver to exchange information. This implies that any event can be considered a messages but not the other way around.
+
+There are several ways to use events in a EDA:
+
+* Events as notifications
+* Events to replicate data

asynchronous-api-guidelines/core-asynchronous-principles/messages/d_basic_concepts_events/events-as-notifications.md

@@ -0,0 +1,7 @@
+# Events as Notifications
+
+When a system uses events as notifications it becomes a plugged system. The producers have no knowledge about the consumers and they don't really care about them, instead every consumer can decide if it is interested in the information included in the event.
+
+This way, the number of consumers can be increased (or reduced) without changing anything on the producer side.
+
+This pluggability becomes increasily important as systems get more complex.

asynchronous-api-guidelines/core-asynchronous-principles/messages/d_basic_concepts_events/events-to-replicate-data.md

@@ -0,0 +1,11 @@
+# Events to Replicate Data
+
+When events are used to replicate data across services, they include all the necessary information for the target system to keep it locally so that it can be queried with no external interactions.
+
+This is usually called event-carried state transfer which in the end is a form of data integration.
+
+The benefits are similar to the ones implied by the usage of a cache system
+
+* Better isolation and autonomy, as the data stays under service's control
+* Faster data access, as the data is local (particularly important when combining data from different services in different geographies)
+* Offline data availability

asynchronous-api-guidelines/core-asynchronous-principles/messages/query.md

@@ -0,0 +1,6 @@
+# Query
+
+It is a special type of message which represents a request to look something up.
+
+* They are always free of side effects (leaves the system unchanged)
+* They always require a response (with the requested data)