Improved doumentation.

dddsample/src/site/apt/architecture.apt

 
   There are three vertical layers: interfaces, application and domain, each supported by different kinds of infrastructure.
 
-* Interfaces
+{Interfaces}
 
-	This layer holds everythng that interacts with other systems, such as web services, RMI interfaces
+	This layer holds everything that interacts with other systems, such as web services, RMI interfaces
 	or web applications, and batch processing frontends. It handles interpretation, validation and translation
 	of incoming data. It also handles serialization of outgoing data, such as HTML or XML across HTTP to
 	web browsers or web service clients, or DTO classes and distributed facade interfaces for remote Java clients.
 
-* Application
+{Application}
 
     The application layer is responsible for defining the use cases of the application, operations that can
     are interface-independent and can be synchronous or message-driven. This layer is well suited for spanning
     The application layer is thin in terms of domain logic - it merely coordinates the domain layer objects
     perform the actual work.
 
-* Domain
+{Domain}
 
 	The domain layer is the heart of the software, and this is where the interesting stuff happens.
 	There is one package per aggregate, and to each aggregate belongs entities, value objects, domain events,
-	a repository interface and sometimes factories. The aggregate roots are Cargo, HandlingEvent, Location and Voyage.
-
-	Everything about determining whether a handling event should be registered and how the delivery of a cargo
-	is affected by handling and belongs in here. The structure and naming of aggregates, classes and methods in
-	should follow the ubiquitous language, and you should be able to explain to a domain expert
+	a repository interface and sometimes factories. The aggregate roots are
+	<<<{{{xref/se/citerus/dddsample/domain/model/cargo/Cargo.html}Cargo}}>>>,
+	<<<{{{xref/se/citerus/dddsample/domain/model/handling/HandlingEvent.html}HandlingEvent}}>>>, 
+	<<<{{{xref/se/citerus/dddsample/domain/model/location/Location.html}Location}}>>> and
+	<<<{{{xref/se/citerus/dddsample/domain/model/voyage/Voyage.html}Voyage}}>>>.
+
+	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
 	of the source code.
 
-* Infrastructure
+{Infrastructure}
 
 	In addition to the three vertical layers, there's 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,

dddsample/src/site/apt/characterization.apt

     The application services in the sample application are responsible for driving workflow and coordinating
     transaction management (by use of the declarative transaction management support in Spring).
     They also provide a high-level abstraction for clients to use when interacting with the domain.
-    These services are typically designed to support specific use cases or fulfill technical requirements (web services, etc).
+    These services are typically designed to define or support specific use cases.
+    See <<<{{{xref/se/citerus/dddsample/application/impl/BookingServiceImpl.html}BookingService}}>>> or
+	<<<{{{xref/se/citerus/dddsample/application/impl/HandlingEventServiceImpl.html}HandlingEventService}}>>>.
 
     In some situations, e.g. when dealing with graphs of lazy-loaded
     domain objects or when passing services' return values over network boundaries, the services are wrapped in facades.
     The facades handle ORM session management issues and/or convert the domain objects to more portable
     {{{http://martinfowler.com/eaaCatalog/dataTransferObject.html}Data Transfer Objects}}) that can be tailored
-    to specific use cases.
-    See <<<{{{xref/se/citerus/dddsample/interfaces/booking/facade/internal/BookingServiceFacadeImpl.html}BookingServiceFacadeImpl}}>>> for an example.
+    to specific use cases. In that case, we consider the DTO-serializing facade part of the {{{architecture.html#Interfaces}interfaces layer}}.
+    See <<<{{{xref/se/citerus/dddsample/interfaces/booking/facade/internal/BookingServiceFacadeImpl.html}BookingServiceFacade}}>>> for an example.

dddsample/src/site/apt/index.apt

   implementation of the building block patterns as well as illustrate the
   impact of aggregates and bounded contexts.
 
+News
+
+  * 2009-03-25: New public release: <<1.1.0>>. See {{{changelog.html}changelog}} for details.
+
+  * 2009-03-09: Sample application tutorial at the {{{http://qconlondon.com/london-2009/}QCon conference}} in London.
+
+  * 2009-01-27: Sample application tutorial at the {{{http://www.jfokus.se/jfokus/}JFokus conference}} in Stockholm.
+
+  * 2008-09-15: First public release: <<1.0>>.
+
 Purpose
 
   * A how-to example for implementing a typical DDD application