Completing chapter 3

Ch03/Ch03.md

@@ -129,22 +129,31 @@ further ado, let us dive into document modeling in RavenDB.
 The reason that we cover modeling on this chapter is that I wanted you to have the chance to get a feeling for some of 
 RavenDB's capabilities before we start discussing modeling techniques. This is because the kind of features that RavenDB has
 to offer are directly relevant to the models you'll write.
-========================
+
 > **RavenDB as the application database**
 >
-> A really important consideration for modeling data in RavenDB is that it is typically used by a _single_ application. RavenDB
-> has a number of feature meant to faciliate data transfer between application databases (builtin ETL processes), and the idea
-> is that an application will be the sole owner of the database.
+> A comoon bad practice is to integrate between different applications using a shared database. This has been known to be a bad
+> idea for quite a while. RavenDB make no attempt to cater to the role of a shared database, instead, it shines in its role as
+> the application database.
+>
+> Typical shared database solution suffer because they attempt to force disparate applications to treat the data in the same 
+> manner. This is a pretty bad idea, since different application tend to have different idea about even very similar concepts.
+> The common example being when you have a billing application and a fullfilment application. Both have the concept of a customer
+> and both actually refer to the same thing when they talk about a customer. But the fullfilment application need to keep track
+> of very different data from the billing application. What will the fullfliment app do with the `CreditScore` field, and what
+> can the billing app gain from looking at the `ShippingManifest` details?
 >
-> This is in contrast to the shared database model, in which a single database is used by multiple applications. The shared model
-> typically result in required coordination between mutiple teams and increased cost of change. In constrast, an application 
-> database is owned by a single application and is much more flexible.
+> Each application should model its data independently, and evolve it as it needs to. Keeping everything in a shared database lead
+> to a of required coordination between the various application teams and result in increased complexity in evolving the 
+> data model as the various applications are being work on.
 > 
-> Data flows between applications is _not_ handled by directly calling into some other application's database. That is important
-> concern for modeling, because you aren't trying to generate an abstract fit all model and compromising about the needs of 
-> multiple applications. When you are modeling, you are focusing on a _single_ application and its needs. If another application
-> need the information we store, it can be supplied by any number of ways (ETL, web service).
-========================
+> However, even though the different applications are separate, they still need to share data between them. How do you do that
+> with RavenDB. We'll talk about this a lot more on [Chapter 7](#integrations), but the answer to that is that each application
+> has its own database, and we can setup information flow between the servers by using RavenDB's builtin ETL capabilities. 
+> 
+> In this way, each application is independent and can evolve and grow on its own, with well defined boundaries and intergation
+> points to its siblings.
+
 We typically encourage you to using DDD techniques for modeling in RavenDB, since they fit so well. A core design principle 
 for modeling documents is that they should be: Independent, Isolated and Coherent.
 
@@ -943,6 +952,25 @@ concepts and aren't limited to the phyiscal world. We then looked at the the iss
 the data and the same _meaning_ of the data. 
 
 The next topic was actual modeling, we looked at how we should structure embedded values to store data that is intrinsically part of the document, instead
-of holding that data outside of the document. We look at how to model relations and collections, many to one and many to many associations and how to 
+of holding that data outside of the document. We looked at how to model relations and collections, many to one and many to many associations. Then we covered
+more advanced modeling techniques, such as how to handle reference and configuration data, how to deal with temporal infromation and deal with hierarchical
+structures.
+
+Next we went over some of the constraints that we have to take into account when modeling. How to deal with the growth of document and what constitute a good
+size for a document in RavenDB. We looked at concurrency control and etags are useful for optimistic concurrency and for caching and why we should avoid caching
+aggregated data in our model (`NumberOfOrders`).
+
+We looked at handling binary data with attachments, auditing and change tracking using the versioning feature and learned that we can expire documents natively
+in RavenDB. Reference handling at indexing and query time was briefly covered (we'll cover it in depth in [Chapter 18](#advanced-indexes)) as it is important
+for how you model your documents.
+
+A repeating theme is the the use of semantic ids to give you better control over documents and their meaning. Not so much for RavenDB's sake^[The database 
+doesn't care what your document ids look like.] but because it increase understanding and visibility in your domain. Using document ids to "nest" documents
+such as `accounts/1234/tx/2017-05` or having meanigful document ids such as `config/states` helps a lot in setting out the structure for your model.
+
+The final topic we covered in this topic is `ACID` vs. `BASE` in RavenDB. Documents in RavenDB are stored and accessed in an `ACID` manner, while we default
+to `BASE` queries to get higher performance and have more chances for optimizations. This behavior is controlled by the user on a case by case basis, so you
+can select the appropriate mode for each scenario.
 
-semantic id
+Our next chapter is going to cover the client API in depth, going over all the tools that you have to create some really awesome behaviors. After that, we'll
+get to running clusters of RavenDB and how the distributed portion of RavenDB is handled.