Minor doc updates.

patrikfr · patrikfr · commit 95d1f5bf3d85 · 2009-03-20T16:58:15.000Z
diff --git a/dddsample/src/site/apt/architecture.apt b/dddsample/src/site/apt/architecture.apt
@@ -8,7 +8,7 @@ Architecture
 
 [images/layers.png]
 
-  There are three vertical layers: interfaces, application and domain, each supported by different kinds of infrastructure.
+  There are three vertical layers: Interfaces, Application and Domain, each supported by different kinds of infrastructure.
 
 {Interfaces}
 
@@ -23,8 +23,8 @@ Architecture
     are interface-independent and can be synchronous or message-driven. This layer is well suited for spanning
     transactions, high-level logging and security.
 
-    The application layer is thin in terms of domain logic - it merely coordinates the domain layer objects
-    perform the actual work.
+    The application layer is thin in terms of domain logic - it merely coordinates workflow and delegates to the domain
+    layer objects to perform the actual work.
 
 {Domain}
 
@@ -39,12 +39,12 @@ Architecture
 	The core of the business logic, such as determining whether a handling event should be registered and how the delivery of a cargo
 	is affected by handling, belongs in here. The structure and naming of aggregates, classes and methods in
 	the domain layer should follow the ubiquitous language, and you should be able to explain to a domain expert
-	how this part of the software works by drawing a few simple diagrams and using the actual class- and method names
+	how this part of the software works by drawing a few simple diagrams and using the actual class and method names
 	of the source code.
 
 {Infrastructure}
 
-	In addition to the three vertical layers, there's also the infrastructure. As the the picture shows, it supports
+	In addition to the three vertical layers, there is also the infrastructure. As the the picture shows, it supports
 	all of the three layers in different ways, facilitating communication between the layers. In simple terms,
 	the infrastructure consists of everything that exists independently of our application: external libraries,
 	database engine, application server, messaging backend and so on.
@@ -53,6 +53,6 @@ Architecture
 	Looking for example at the persistence aspect, the database schema definition, Hibernate configuration and mapping files
 	and implementations of the repository interfaces are part of the infrastructure layer.
 
-	While it can be tricky to give a waterproof definition of what kind of code belongs to the infrastructure layer for any given situation,
+	While it can be tricky to give a solid definition of what kind of code belongs to the infrastructure layer for any given situation,
 	it should be possible to completely stub out the infrastructure in pure Java unit/scenario tests and still be able to
 	use the domain layer and possibly the application layer to work out the core business problems.
diff --git a/dddsample/src/site/apt/characterization.apt b/dddsample/src/site/apt/characterization.apt
@@ -39,7 +39,6 @@ Characterization
 
     The main reason for not making <<<HandlingEvent>>> part of the cargo aggregate is performance. <<<HandlingEvent>>>s are received from external parties and systems, e.g. warehouse management systems, port handling systems, that call our <<<{{{xref/se/citerus/dddsample/interfaces/handling/ws/HandlingReportServiceImpl.html}HandlingReportService}}>>> webservice implementation. The number of events can be very high and it is important that our webservice can dispatch the remote calls quickly. To be able to support this use case we need to handle the remote webservice calls asynchronously, i.e. we do not want to load the big cargo structure synchronously for each received <<<HandlingEvent>>>. Since all relationships in an aggregate must be handled synchronously we put the <<<HandlingEvent>>> in an aggregate of its own and we are able processes the events quickly and at the same time eliminate dead-locking situations in the system.
     
-[images/aggregates.gif]
 
 {Repositories}
 
diff --git a/dddsample/src/site/apt/download.apt b/dddsample/src/site/apt/download.apt
@@ -42,7 +42,7 @@ mvn jetty:run
 
     The start page is available at {{http://localhost:8080/dddsample}}, and has links to the various interfaces.
 
-	There is a screencast available on the project site that demonstrates how the different interfaces are used.
+	There is a {{{screencast.html}screencast}} available on the project site that demonstrates how the different interfaces are used.
 
     An RMI registry will be started on port <<<1099>>>, in addition to the Jetty container on port <<<8080>>>, so those ports
     need to be available or you have to reconfigure the application.
diff --git a/dddsample/src/site/apt/index.apt b/dddsample/src/site/apt/index.apt
@@ -48,7 +48,7 @@ Purpose
 Caveats
 
   	Domain-driven design is a very broad topic, and contains lots of things that are difficult or impossible
-    to incorporate into the code base of a sample application, most importantly communication with the domain
+    to incorporate into the code base of a sample application. Perhaps most important is communication with the domain
     expert, iterative modelling and the discovery of a ubiquitous language. This application is a snapshot in time,
     the result of a development effort that you need to imagine has been utilizing domain-driven design,
     to show how one can structure an application around an isolated, rich domain model in a realistic environment.
diff --git a/dddsample/src/site/apt/roadmap.apt b/dddsample/src/site/apt/roadmap.apt
@@ -11,4 +11,4 @@ Roadmap
   * Handling voyage delays and intentional rescheduling, how that affects itineraries
 
   * More one the time aspect: timezones for locations and handling events,
-    notify on delayed delivery, port to TimeAndMoney or similar date/time framework
+    notify on delayed delivery, port to {{{http://timeandmoney.sourceforge.net/}TimeAndMoney}} or similar date/time framework
diff --git a/dddsample/src/site/xdoc/screencast.xml b/dddsample/src/site/xdoc/screencast.xml
@@ -10,7 +10,7 @@
   <body>
     <section name="Screencast">
       <p>
-        Here's a 10 minute screencast that shows the different interfaces in action.
+        Here is a 10 minute screencast that shows the different interfaces in action.
       </p>
       <object width="425" height="344">
         <param name="movie" value="http://www.youtube.com/v/eA8xgdtqqs8&amp;hl=en&amp;fs=1"></param>

Original file line number	Diff line number	Diff line change
`@@ -39,7 +39,6 @@ Characterization`
`39`	`39`
`40`	`40`	The main reason for not making <<<HandlingEvent>>> part of the cargo aggregate is performance. <<<HandlingEvent>>>s are received from external parties and systems, e.g. warehouse management systems, port handling systems, that call our <<<{{{xref/se/citerus/dddsample/interfaces/handling/ws/HandlingReportServiceImpl.html}HandlingReportService}}>>> webservice implementation. The number of events can be very high and it is important that our webservice can dispatch the remote calls quickly. To be able to support this use case we need to handle the remote webservice calls asynchronously, i.e. we do not want to load the big cargo structure synchronously for each received <<<HandlingEvent>>>. Since all relationships in an aggregate must be handled synchronously we put the <<<HandlingEvent>>> in an aggregate of its own and we are able processes the events quickly and at the same time eliminate dead-locking situations in the system.
`41`	`41`
`42`		`-[images/aggregates.gif]`
`43`	`42`
`44`	`43`	`{Repositories}`
`45`	`44`