Run prettier everywhere

antipatterns/mvcs-antipatterns.md

@@ -1,5 +1,6 @@
 <!-- START doctoc generated TOC please keep comment here to allow auto update -->
 <!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
+
 # Table of Contents
 
 - [MVCS Antipatterns](#mvcs-antipatterns)
@@ -7,15 +8,13 @@
 
 <!-- END doctoc generated TOC please keep comment here to allow auto update -->
 
-MVCS Antipatterns
-=================
+# MVCS Antipatterns
 
 In simple terms, Model-View-Controller-Services add a few more layers to the
 MVC pattern. The main one is the service, which owns all the core business
 logic and manipulate the repository layer.
 
-Creating entities for association tables
-----------------------------------------
+## Creating entities for association tables
 
 You'll often need association tables, for instance to set up a many to many
 relationships between users and their toasters. Let's assume that a toaster can
@@ -51,18 +50,18 @@ Heart of Software. Pearson Education. Kindle Edition.
 Entities should model business processes, not persistence details
 ([source](http://blog.sapiensworks.com/post/2013/05/13/7-Biggest-Pitfalls-When-Doing-Domain-Driven-Design.aspx/)).
 
-* In that case, `UserToaster` does not map to anything the business is using.
+- In that case, `UserToaster` does not map to anything the business is using.
   Using plain English, somebody might ask about "what toasters does user
   A owns?" or "who owns toaster B and since when?" Nobody would ask "give me
   the UserToaster for user A".
-* The association table can be considered an implementation detail that should
+- The association table can be considered an implementation detail that should
   not (in most cases) leak in the domain layer. All the code should be dealing
   with the simpler logic of "user having toasters", not UserToaster objects
   being an association between a user and a toaster. This makes the code more
   intuitive and natural.
-* It will be easier to handle serializing a "user having toasters" than
+- It will be easier to handle serializing a "user having toasters" than
   serializing UserToaster association.
-* This will make it very easy to force the calling site to take care of some
+- This will make it very easy to force the calling site to take care of some
   business logic. For instance, you might be able to get all `UserToaster`, and
   then filter on whether they were bought. You might be tempted to do that by
   going through the `UserToaster` object and filtering those that have
@@ -72,11 +71,11 @@ Entities should model business processes, not persistence details
 
 So in that case, I would recommend doing the following:
 
-* Create a `User` and `Toaster` entity.
-* Put the association properties on the entity that makes sense, for instance
+- Create a `User` and `Toaster` entity.
+- Put the association properties on the entity that makes sense, for instance
   `owned_since` would be on `Toaster`, even though in the database it's stored
   on the association table.
-* If filtering on association properties is required, put this logic in
+- If filtering on association properties is required, put this logic in
   repositories. In plain English, you would for instance ask "give all the
   toasters user A owned in December?", you wouldn't ask "give be all the
   UserToaster for owned by user A in December".
@@ -109,7 +108,7 @@ unidirectional user->toasters.
 
 Sources:
 
-* [7 Biggest Pitfalls When Doing Domain Driven
+- [7 Biggest Pitfalls When Doing Domain Driven
   Design](http://blog.sapiensworks.com/post/2013/05/13/7-Biggest-Pitfalls-When-Doing-Domain-Driven-Design.aspx/)
-* [Domain-Driven Design: Tackling Complexity in the Heart of
+- [Domain-Driven Design: Tackling Complexity in the Heart of
   Software](http://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215)