Domain Driven Design &
Development with Spring Portfolio
Srini Penchikala
Ann Arbor Java User Group
February 24, 2009

About the Speaker
• Enterprise Architect
• Writer: InfoQ, TSS, ONJava, DevX Java, java.net
• Speaker
• Detroit Java User Group Leader
• Using Java/JEE since 2000
• SOA/Web Services since 2006
• PowerPoint since September 2008
2

Presentation Goal
“What” Domain Driven Design (DDD) is and “How”
Spring Portfolio helps in implementing a DDD project
3

Format
Interactive

Demos

Duration: ~45 minutes

Q&A

4

Before we start…
• How many have heard of Domain Driven Design before?
• How many are currently using DDD?
5

Agenda
• Domain Driven Design & Development
• Spring Portfolio
• Dependency Injection / AOP / Annotations
• Spring Security (Demo)
• Architecture Enforcement (Demo)
• Code Generation (Demo)
• Conclusions
6

Agenda
• Domain Driven Design & Development
• Spring Portfolio
• Dependency Injection / AOP / Annotations
• Spring Security (Demo)
• Architecture Enforcement (Demo)
• Code Generation (Demo)
• Conclusions
7

Layered Architecture Diagram
8

Architecture Layers
User Interface

Application

Domain

Infrastructure

9

Domain Layer
Represents concepts of business,

information about business situation, and
business rules.
Maintains state reflecting the business

situation.
This layer is the heart of business

software*.
10

J2EE Architecture Model
HTTP
Application Controller
Session Management
Transaction Management
Facade
Caching
Data Access Data Access Object
Persistence Domain Object
*
Notes:
• No real Domain Layer
• Business Logic in Façade Layer (Stateless
Session Beans )
• Direct Access to Data Access Objects
(CRUD logic is infrastructure not business
)
• *Domain objects are really Persistence
Data Store classes with getters
/setters
Database • Infrastructure concerns have overtaken/
overshadowed the domain concerns
11

The Problem
Architects/Developers are thinking only about

infrastructure.
Most of the development time is still spent on

writing plumbing code instead of real business
logic.
We have lost real OOP

12

Domain Driven Architecture
13

Domain Driven Design &
Development
14

Domain Driven Design
What:
Domain Driven Design (DDD) is about

mapping business domain concepts into
software artifacts.
Why:
To create better software by focusing on a

model of the domain rather than the
technology.
15

Domain Driven Design
Is not a:

new technology

new framework

JSR standard

Is a:

design pattern

16

Advantages
Promotes high cohesion and low coupling

in the application code
Easy to test domain components

Business (domain) logic is isolated from

non-domain and infrastructure code
Adding/changing services does not

influence the domain or other services.
17

Development Styles
Transaction Script

Table Module

Domain Model

18

Development Styles
A single instance that handles the
•
business logic for all rows in a database
table or view.
Choose the right style for the right application/service
Source: Patterns of Enterprise Application Architecture, Martin Fowler 19

DDD Manifesto
(Business) Domain Infrastructure
Domain State & Behavior Persistence
 
Business Logic Transaction Management
 
Business Rules Remoting
 
Scheduling

20

Domain Objects
Domain objects are instances of real

entities which hold any knowledge or
activity of the business domain.
21

Main Elements
Entities

Objects defined by their identity, which remains

same throughout the life of software
Value Objects

Immutable objects that have no identity & are used

to describe an attribute of another object.
(Domain) Services

Objects that have no state & only have a defined

behavior that’s not part of any domain object.
22

Other Elements
Module:

A method of organizing related concepts and tasks

in order to reduce complexity.
Domain object Lifecycle is managed by:

Aggregate

Factory

Repository

23

DDD Thought Process
Start with domain entities and domain logic

Basic domain-driven & object-oriented principles

Mentally start without a \"service\" layer

See how far you can get

Add service level as required

You can refactor to DDD

Source: Domain Driven Design with AOP and DI, Presentation by
Ramnivas Laddad 24

DDD Lifecycle Diagram
25

Agenda
• Domain Driven Design & Development
• Spring Portfolio
• Dependency Injection / AOP / Annotations
• Spring Security (Demo)
• Architecture Enforcement (Demo)
• Code Generation (Demo)
• Conclusions
26

Spring Framework
• Separation of concerns (business v.
infrastructure)
• POJO Based Design
• Business domain first, infrastructure concerns
second
• Agile Development and Testing
27

Spring Philosophy
28

Spring Portfolio
Spring Core

Spring AOP

Spring Security

Spring MVC/Spring WebFlow

29

The Project
Project Management

Agile Methodology (SCRUM)

Iterative Design, Development, Unit Testing and

Refactoring.
Architecture

Focus on business domain & alignment with

business model
Isolation & Modularity

Loosely coupled with other layers

30
POJO programming model.


Agenda
• Domain Driven Design & Development
• Spring Portfolio
• Dependency Injection / AOP / Annotations
• Spring Security (Demo)
• Architecture Enforcement (Demo)
• Code Generation (Demo)
• Conclusions
31

Design Recipe
Object Oriented Programming (OOP)

Dependency Injection (DI)

Aspect-oriented Programming (AOP)

Annotations

32

DDD with OOP Principles
Domain Element State/Behavior
Entity, Value Object, State and Behavior
Aggregate
Data Transfer Object State only
Service, Repository Behavior only
33

Dependency Injection
• Decouple and manage the dependencies of
the components in the application
• DI Frameworks:
• Spring
• Google Guice
• Pico Container
34

DI Use Cases
Service

Domain Classes

Transaction Manager

Domain

Data Access Object (DAO)

DAO class

Data Source

JPA Entity Manager

35

Domain Object DI
• @Configurable annotation
36

Aspect-oriented Programming
• Allows developers to add behavior to objects
in a non-obtrusive manner through use of
static and dynamic crosscutting.
• Main goal is to code cross-cutting concerns in
separate modules and apply them in a
declarative way.
37

AOP Use Cases
Framework Built-In Aspects

Transaction Management

Security

Custom Aspects

Profiling

Caching

Rules

38

Annotations
• Added in Java SE 5.0 as Java Metadata
facility (JSR 175).
• Provide a way to add metadata to program
elements.
• Defined by nearly every recent JSR standard.
• Also include a mechanism for adding custom
annotations to the Java code*.
39

Annotations For Domain Elements
Layer Domain Element Annotation
Domain
Entity, @Entity (JPA),
Value Object @Configurable
Domain Repository @Repository
Domain Service @Service
Application Controller @Controller
All All @Component
40

Custom Annotations Use Cases
• Caching
• Validation
41

Custom Annotations
• Implementation Options
• Reflection
• Annotation Processing Tool (APT)
• Byte-code Instrumentation (Javassist)
• Aspects/AOP (AspectJ and Spring AOP)
42

Agenda
• Domain Driven Design & Development
• Spring Portfolio
• Dependency Injection / AOP / Annotations
• Spring Security (Demo)
• Architecture Enforcement (Demo)
• Code Generation (Demo)
• Conclusions
43

Domain Aspects
Data Access

Persistence

Transaction Management

Domain Security

Business Operation Retry

Caching

44

Persistence & Txn Management
JDBC

JPA w/ Hibernate, OpenJPA, EclipseLink

(TopLink)
Spring JPA Utils & Data Source DI

Spring JTA Support

– Transactions are managed in Service classes
using \"@Transactional\" annotation
45

Spring Security
Declarative Application Security support

Fits in very well with Spring Framework

Authentication

Authorization

URL level

Domain Object

Service Method

46

DEMO
47

Agenda
• Domain Driven Design & Development
• Spring Portfolio
• Dependency Injection / AOP / Annotations
• Spring Security (Demo)
• Architecture Enforcement (Demo)
• Code Generation (Demo)
• Conclusions
48

Architecture Enforcement
• Domain Driven Design Rules
• Enforcement using Aspects and AOP
49

Rules – Compile Time
Service classes should not depend on

Application layer classes
DAO classes should only be called from

Domain classes
50

DEMO
51

Rules – Run Time
Business operation retry

Caching

System Settings (using AOP)

Application Variables/Business Data (using

Annotations)
52

DEMO
53

Agenda
• Domain Driven Design & Development
• Spring Portfolio
• Dependency Injection / AOP / Annotations
• Spring Security (Demo)
• Architecture Enforcement (Demo)
• Code Generation (Demo)
• Conclusions
54

Code Generation
Write:
XSD

Domain / Service

Code Generate:
DAO interface and implementation

Facade (EJB's & WebServices)

DTO's

Unit Tests (including test data)

Spring configuration files

55

Code Generation Tools
openArchitectureWare (oAW)

AndroMDA

Aceleo Spring Module

Skyway Builder

56

DEMO
57

Tools
Spring for:

Scheduling (Quartz)

Configuration Management (Commons

Configuration, JMX)
Hibernate Tools (for DDL generation)

Dozer (DO/DTO Assembly)

58

DDD Lifecycle Diagram Revisited
59

Agenda
• Domain Driven Design & Development
• Spring Portfolio
• Dependency Injection / AOP / Annotations
• Spring Security (Demo)
• Architecture Enforcement (Demo)
• Code Generation (Demo)
• Conclusions
60

Conclusions
• Domain First, Infrastructure Second
• Layered Architecture & Separation of Concerns
• Always keep the \"context\" in mind
• Balance between the \"right\" vs. the \"right now\"
• Upcoming Java/JEE releases focus on development
& deployment simplicity
• Spring 3.0, Java EE 6, JPA 2.0, EJB 3.1
61

References
• Domain Driven Design and Development In Practice
(http://www.infoq.com/articles/ddd-in-practice)
• Domain-Driven Design Website
(http://www.domaindrivendesign.org/)
• Domain-Driven Design by Eric Evans
• Applying Domain-Driven Design and Patterns, Jimmy
Nilsson
• Patterns of Enterprise Application Architecture, Martin
Fowler
• Can DDD be Adequately Implemented Without DI and
AOP (http://www.infoq.com/news/2008/02/ddd-di-aop)
62

Contact Information
• Domain-Driven Design and Enterprise Architecture
articles on InfoQ.
• InfoQ website (http://www.infoq.com)
• E-Mail: srinipenchikala@gmail.com
• Blog: http://srinip2007.blogspot.com
63

Q&A
64

Thank You
• Thank you for your attention
• Feedback survey
65