Srini Penchikala

Domain Driven Design and Development In Practice - Code Generation

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).

Architecture Rules Enforcement using Aspects

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.

Domain Event Driven Architectures using Aspects and Event Stream Processing

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.