These are the sample Bounded Contexts from the book "Implementing Domain-Driven Design" by Vaughn Vernon: http://vaughnvernon.co/?page_id=168 The models and surrounding architectural mechanisms may be in various states of flux as the are refined over time. Some tests may be incomplete. The code is not meant to be a reflection of a production quality work, but rather as a set of reference projects for the book. Points of Interest ------------------ The iddd_agilepm project uses a key-value store as its underlying persistence mechanism, and in particular is LevelDB. Actually the LevelDB in use is a pure Java implementation: https://github.com/dain/leveldb Currently iddd_agilepm doesn't employ a container of any kind (such as Spring). The iddd_collaboration project uses Event Sourcing and CQRS. It purposely avoids the use of an object-relational mapper, showing that a simple JDBC-based query engine and DTO matter can be used instead. This technique does have its limitations, but it is meant to be small and fast and require no configuration or annotations. It is not meant to be perfect. It may be helpful to make one additional mental note on the iddd_collaboration CQRS implementation. To keep the example simple it persists the Event Sourced write model and the CQRS read model in one thread. Since two different stores are used--LevelDB for the Event Journal and MySQL for the read model--there may be very slight opportunities for inconsistency, but not much. The idea was to keep the two models as close to consistent as possible without using the same data storage (and transaction) for both. Two different storage mechanisms were used purposely to demonstrate that they can be separate. The iddd_identityaccess project uses uses object-relational mapping (Hibernate), but so as not to leave it "boring" it provides a RESTful client interface and even publishes Domain-Event notifications via REST (logs) and RabbitMQ. Finally the iddd_common project provides a number of reusable components. This is not an attempt to be a framework, but just leverages reuse to the degree that code copying doesn't liter each project. This is not a recommendation, but it did work well and save a considerable amount of work while producing the samples. Build and Dependencies ---------------------- A local dependency cache was used during development, and the final build will be missing for a few more days. I will use Gradle, and need to provide support for maven/ivy repository. Until the time that the build is completed, this is a list of dependencies in the local cache: antlr-2.7.6.jar aspectjweaver.jar cglib-nodep-2.1_3.jar commons-codec-1.2.jar commons-collections-3.1.jar commons-dbcp-1.4.jar commons-httpclient-3.1.jar commons-logging-1.1.1.jar commons-pool-1.6.jar dom4j-1.6.1.jar gson-2.1.jar guava-12.0.jar hibernate3.jar javassist-3.8.0.GA.jar jaxrs-api-2.0.1.GA.jar jettison-1.2.jar jta-1.1.jar junit-3.8.2.jar junit-4.8.2.jar leveldb-0.6-SNAPSHOT.jar leveldb-api-0.6-SNAPSHOT.jar mail-1.4.jar mysql-connector-java-5.1.6-bin.jar persistence-api-1.0.jar rabbitmq-client.jar resteasy-atom-provider-2.0.1.GA.jar resteasy-cache-core-2.0.1.GA.jar resteasy-cdi-2.0.1.GA.jar resteasy-fastinfoset-provider-2.0.1.GA.jar resteasy-guice-2.0.1.GA.jar resteasy-jackson-provider-2.0.1.GA.jar resteasy-jaxb-provider-2.0.1.GA.jar resteasy-jaxrs-2.0.1.GA.jar resteasy-jettison-provider-2.0.1.GA.jar resteasy-jsapi-2.0.1.GA.jar resteasy-links-2.0.1.GA.jar resteasy-multipart-provider-2.0.1.GA.jar resteasy-oauth-2.0.1.GA.jar resteasy-spring-2.0.1.GA.jar resteasy-yaml-provider-2.0.1.GA.jar scannotation-1.0.2.jar servlet-api-2.5.jar slf4j-api-1.5.8.jar slf4j-simple-1.5.8.jar snappy-0.2.jar spring.jar tjws-2.0.1.GA.jar A few of these jar files may actually not be used, but I won't try to sort that out at the moment. That's it for now. I hope you benefit from the samples. Vaughn Vernon Author: Implementing Domain-Driven Design Twitter: @VaughnVernon http://vaughnvernon.co/