The document discusses the benefits of exercise for mental health. Regular physical activity can help reduce anxiety and depression and improve mood and cognitive function. Exercise causes chemical changes in the brain that may help alleviate symptoms of mental illness and boost overall mental well-being.

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

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

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

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

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

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

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

8. Layered Architecture Diagram
8

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

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

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

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

13. Domain Driven Architecture
13

14. Domain Driven Design &
Development
14

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

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

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

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

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

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

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

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

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

24. DDD Thought Process
Start with domain entities and domain logic

Basic domain-driven & object-oriented principles

Mentally start without a quot;servicequot; 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

25. DDD Lifecycle Diagram
25

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

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

28. Spring Philosophy
28

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

30. 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.


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

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

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

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

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

36. Domain Object DI
• @Configurable annotation
36

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

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

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

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

41. Custom Annotations Use Cases
• Caching
• Validation
41

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

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

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

45. 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 quot;@Transactionalquot; annotation
45

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

47. DEMO
47

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

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

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

51. DEMO
51

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

53. DEMO
53

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

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

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

57. DEMO
57

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

59. DDD Lifecycle Diagram Revisited
59

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

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

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

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

64. Q&A
64

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