Domain Driven Design (DDD) technique helps architects and developers in mapping business domain concepts to software artifacts. When applying DDD techniques in a Java application, there are several domain classes and other artifacts (like configuration files) in Domain, Service and Application architecture layers that can be automatically generated using Code Generation techniques. For example, in a typical web application same data flows through the application layers in different forms like Domain Object (DO), Data Transfer Object (DTO) and XML. The developers usually write these classes manually from scratch or write the first class and then copy and paste when they need the classes for other use cases. These and other classes like Facade, Data Access Object (DAO interface, implementation and the unit test classes) are good candidates for code generation.

Code generation helps the software development process by generating consistent code for the classes and other artifacts that have infrastructure (boiler-plate) logic but don't have any business logic. It fits in very well with Domain Driven Design philosophy of "Domain First, Infrastructure Second" where the developers can focus on business domain concerns and take the advantage of code generation to address the infrastructure concerns. If Domain Driven Design provides the "What", it is the code generation, as a development technique, that can provide the "How". Code generation is a good long-term solution even though this effort involves some initial investment (in terms of coding and time) which pays itself off in medium to large domain models.

This technical session will discuss the role of code generation in a Java web application from the Domain Driven Design and Development context. I will start off the presentation with a quick overview of the Layered Architecture in a typical web application that was developed using DDD design pattern and implemented using Spring Framework (for middleware services) and JPA (with Hibernate3) for persistence. I will talk about the code generation concept in the project, that starts with the creation of a standard and consistent project template (using Maven Archetype feature). The discussion will include a list of the classes we need to write from scratch (like XSD, Domain Object and Service) and then code generate the Java classes and configuration files in domain and other layers (like DAO's, Factories, Repositories, Delegates, DTO's, Unit Tests, and Spring configuration files).

The presentation will include a demo of the Java application to show how domain elements and artifacts can be code generated using tools like openArchitectureWare (oAW), Eclipse, Maven, and Spring. The session will conclude with the design guidelines and best practices to follow when considering code generation as part of implementing a Business Domain Model.

Even though many companies have some kind of application architecture standards, they don't usually have a mechanism to enforce those standards. As a result of this lack of architecture governance, the Implementation (Code) often doesn't match the Requirements (Reference Architecture). Enforcing Reference Architecture guidelines promotes consistency and modularity in the System. It also helps in detecting structural complexity and preventing it earlier in the software development process. As a result, the application code is modifiable, portable, and testable.

In this presentation, I will talk about the significance of enforcing the architecture rules and standards and how to actually enforce them in software development projects. I will start off the discussion explaining various types of architecture rules that range from simple module dependencies to enforcing how APIs and specific idioms should be used. All these rules usually fall into categories such as Layered Architecture, Separation Of Concerns, Domain Driven Design, and Infrastructure. Some of the rules examples will include basic validations like DAO (Persistence) layer shouldn't depend on any other layers, Presentation layer should not use DAO classes directly, and Service layer should never call web layer. Separation of concerns rules are no transaction management in DAO classes and Service layer should be transactional. More sophisticated rules like that are used in a Domain Driven Design project such as Service object creation through a Factory object (i.e. no Service instantiation using the new keyword), No direct access to DAO's except from the Domain classes (go through Domain or Repository objects), and Business service that fails with a concurrency related failure can be retried.

The presentation will also include the discussion on Static and Dynamic Analysis architecture enforcement setup types and the techniques and tools architects can use for the enforcing the rules. Some of these techniques include Aspect-Oriented Programming (AOP), AspectJ Design Level Assertions (DLA's) and Design by Contract (DbC). As for the tools, Macker can be used for identifying module (package) dependency violations and other tools like Contract4J, SonarJ and Lattix can be used for more comprehensive rules enforcement. The session will include a demo of enforcing architecture rules in a sample Java application using Aspects as well as SonarJ tool. The attendees will be able to take away the techniques and tools discussed in the presentation back to their projects and start using them in their applications right away.

This presentation will give an overview of using Aspects/AOP to implement business domain event processing logic and Event Stream Processing (ESP) to analyze the event data streams in real-time. The presentation uses a sample application to demonstrate the use of ESP in a loan processing application. The sample application uses technologies like AspectJ, Spring AOP, and Esper (ESP container) to intercept the business domain events and process them based on pre-defined event processing queries. The application also uses ActiveMQ (JMS), JMX, and Groovy to add asynchronous messaging and application monitoring.

In a typical domain model run-time environment, several business events occur in the business process life cycle. Each of these domain events require further processing to either manage the domain state, notify other business processes, monitor the events or analyze event details for some type of decision-making. There are several reasons why event processing logic should not be coupled with the domain logic. This is where Domain Event Driven Architecture comes to the rescue where the event interception and management logic are defined in separate modules and are dynamically wired together to inject the event logic into the domain implementation code. The event data analysis is done using Event Stream Processing (ESP) techniques.

This presentation will give an overview of using Aspects/AOP to implement business domain event processing logic and Event Stream Processing (ESP) to analyze the event data streams in real-time. The presentation uses a sample application to demonstrate the use of ESP in a loan processing application. The sample application uses technologies like AspectJ, Spring AOP, and Esper (ESP container) to intercept the business domain events and process them based on pre-defined event processing queries. The application also uses ActiveMQ (JMS), JMX, and Groovy to add asynchronous messaging and application monitoring.