robertbasic · October 26, 2017 11:52 · Oct 26, 2017 · Oct 26, 2017 · Oct 26, 2017 · Oct 26, 2017
diff --git a/abstract.md b/abstract.md
@@ -8,5 +8,5 @@ Our solutions should be driven by our clients and what they really need. We need
 
 This presentation will show why we should become better communicators, and how we can use Domain Driven Design to bridge 
 this communication gap. Creating an ubiquitous language that we share with our clients, we model their world in ours. These
-models live in bounded contexts, made out of aggregate roots, domain events, entities, value objects... all here to guide
+models live in bounded contexts, made out of aggregate roots, domain events, entities, value objects, that are all here to guide
 us to create better solutions, and write better software.
diff --git a/abstract.md b/abstract.md
@@ -7,5 +7,6 @@ at the keyboard. Few weeks, months later, we come back with a solution to all of
 Our solutions should be driven by our clients and what they really need. We need to listen to them, talk to them, understand them.
 
 This presentation will show why we should become better communicators, and how we can use Domain Driven Design to bridge 
-this communication gap. Creating an ubiquitous language that we share with our clients, we model their world in ours. These 
-models will guide us to create better solutions, and write better software.
+this communication gap. Creating an ubiquitous language that we share with our clients, we model their world in ours. These
+models live in bounded contexts, made out of aggregate roots, domain events, entities, value objects... all here to guide
+us to create better solutions, and write better software.
diff --git a/abstract.md b/abstract.md
@@ -7,5 +7,5 @@ at the keyboard. Few weeks, months later, we come back with a solution to all of
 Our solutions should be driven by our clients and what they really need. We need to listen to them, talk to them, understand them.
 
 This presentation will show why we should become better communicators, and how we can use Domain Driven Design to bridge 
-this communication gap. Using the same language as our clients, we model their world in ours. These models will guide us
-to create better solutions, and write better software.
+this communication gap. Creating an ubiquitous language that we share with our clients, we model their world in ours. These 
+models will guide us to create better solutions, and write better software.
diff --git a/abstract.md b/abstract.md
@@ -4,8 +4,7 @@ Our clients come to us to solve their problems using software. We listen to thei
 have a meeting or two, and then we take out our favourite code editor, framework and database, and start pounding
 at the keyboard. Few weeks, months later, we come back with a solution to all of their problems. Or is it, really?
 
-Our solutions should not be driven by our tools. Our solutions should be driven by our clients and what they really need.
-We need to listen to them, talk to them, understand them.
+Our solutions should be driven by our clients and what they really need. We need to listen to them, talk to them, understand them.
 
 This presentation will show why we should become better communicators, and how we can use Domain Driven Design to bridge 
 this communication gap. Using the same language as our clients, we model their world in ours. These models will guide us

diff --git a/abstract.md b/abstract.md
@@ -7,6 +7,6 @@ at the keyboard. Few weeks, months later, we come back with a solution to all of
 Our solutions should not be driven by our tools. Our solutions should be driven by our clients and what they really need.
 We need to listen to them, talk to them, understand them.
 
-This presentation will show wy we should become better communicators, and how we can use Domain Driven Design to bridge 
+This presentation will show why we should become better communicators, and how we can use Domain Driven Design to bridge 
 this communication gap. Using the same language as our clients, we model their world in ours. These models will guide us
 to create better solutions, and write better software.
diff --git a/abstract.md b/abstract.md
@@ -0,0 +1,12 @@
+# introDDDuction
+
+Our clients come to us to solve their problems using software. We listen to their pitch, we read their emails, 
+have a meeting or two, and then we take out our favourite code editor, framework and database, and start pounding
+at the keyboard. Few weeks, months later, we come back with a solution to all of their problems. Or is it, really?
+
+Our solutions should not be driven by our tools. Our solutions should be driven by our clients and what they really need.
+We need to listen to them, talk to them, understand them.
+
+This presentation will show wy we should become better communicators, and how we can use Domain Driven Design to bridge 
+this communication gap. Using the same language as our clients, we model their world in ours. These models will guide us
+to create better solutions, and write better software.