Domain Driven Design Development Spring Portfolio

11,455 views

Published on

This is a presentation I gave at Ann Arbor Java User Group (AAJUG) last week on Domain Driven Design and Development Using Spring Portfolio projects.

Published in: Technology
1 Comment
49 Likes
Statistics
Notes
No Downloads
Views
Total views
11,455
On SlideShare
0
From Embeds
0
Number of Embeds
443
Actions
Shares
0
Downloads
0
Comments
1
Likes
49
Embeds 0
No embeds

No notes for slide

Domain Driven Design Development Spring Portfolio

  1. 1. Domain Driven Design & Development with Spring Portfolio Srini Penchikala Ann Arbor Java User Group February 24, 2009
  2. 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. 3. Presentation Goal “What” Domain Driven Design (DDD) is and “How” Spring Portfolio helps in implementing a DDD project 3
  4. 4. Format Interactive  Demos  Duration: ~45 minutes  Q&A  4
  5. 5. Before we start… • How many have heard of Domain Driven Design before? • How many are currently using DDD? 5
  6. 6. Agenda • Domain Driven Design & Development • Spring Portfolio • Dependency Injection / AOP / Annotations • Spring Security (Demo) • Architecture Enforcement (Demo) • Code Generation (Demo) • Conclusions 6
  7. 7. Agenda • Domain Driven Design & Development • Spring Portfolio • Dependency Injection / AOP / Annotations • Spring Security (Demo) • Architecture Enforcement (Demo) • Code Generation (Demo) • Conclusions 7
  8. 8. Layered Architecture Diagram 8
  9. 9. Architecture Layers User Interface  Application  Domain  Infrastructure  9
  10. 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. 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. 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. 13. Domain Driven Architecture 13
  14. 14. Domain Driven Design & Development 14
  15. 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. 16. Domain Driven Design Is not a:  new technology  new framework  JSR standard  Is a:  design pattern  16
  17. 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. 18. Development Styles Transaction Script  Table Module  Domain Model  18
  19. 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. 20. DDD Manifesto (Business) Domain Infrastructure Domain State & Behavior Persistence   Business Logic Transaction Management   Business Rules Remoting   Scheduling  20
  21. 21. Domain Objects Domain objects are instances of real  entities which hold any knowledge or activity of the business domain. 21
  22. 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. 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. 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. 25. DDD Lifecycle Diagram 25
  26. 26. Agenda • Domain Driven Design & Development • Spring Portfolio • Dependency Injection / AOP / Annotations • Spring Security (Demo) • Architecture Enforcement (Demo) • Code Generation (Demo) • Conclusions 26
  27. 27. Spring Framework • Separation of concerns (business v. infrastructure) • POJO Based Design • Business domain first, infrastructure concerns second • Agile Development and Testing 27
  28. 28. Spring Philosophy 28
  29. 29. Spring Portfolio Spring Core  Spring AOP  Spring Security  Spring MVC/Spring WebFlow  29
  30. 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. 31. Agenda • Domain Driven Design & Development • Spring Portfolio • Dependency Injection / AOP / Annotations • Spring Security (Demo) • Architecture Enforcement (Demo) • Code Generation (Demo) • Conclusions 31
  32. 32. Design Recipe Object Oriented Programming (OOP)  Dependency Injection (DI)  Aspect-oriented Programming (AOP)  Annotations  32
  33. 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. 34. Dependency Injection • Decouple and manage the dependencies of the components in the application • DI Frameworks: • Spring • Google Guice • Pico Container 34
  35. 35. DI Use Cases Service  Domain Classes  Transaction Manager  Domain  Data Access Object (DAO)  DAO class  Data Source  JPA Entity Manager  35
  36. 36. Domain Object DI • @Configurable annotation 36
  37. 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. 38. AOP Use Cases Framework Built-In Aspects  Transaction Management  Security  Custom Aspects  Profiling  Caching  Rules  38
  39. 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. 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. 41. Custom Annotations Use Cases • Caching • Validation 41
  42. 42. Custom Annotations • Implementation Options • Reflection • Annotation Processing Tool (APT) • Byte-code Instrumentation (Javassist) • Aspects/AOP (AspectJ and Spring AOP) 42
  43. 43. Agenda • Domain Driven Design & Development • Spring Portfolio • Dependency Injection / AOP / Annotations • Spring Security (Demo) • Architecture Enforcement (Demo) • Code Generation (Demo) • Conclusions 43
  44. 44. Domain Aspects Data Access  Persistence  Transaction Management  Domain Security  Business Operation Retry  Caching  44
  45. 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. 46. Spring Security Declarative Application Security support  Fits in very well with Spring Framework  Authentication  Authorization  URL level  Domain Object  Service Method  46
  47. 47. DEMO 47
  48. 48. Agenda • Domain Driven Design & Development • Spring Portfolio • Dependency Injection / AOP / Annotations • Spring Security (Demo) • Architecture Enforcement (Demo) • Code Generation (Demo) • Conclusions 48
  49. 49. Architecture Enforcement • Domain Driven Design Rules • Enforcement using Aspects and AOP 49
  50. 50. Rules – Compile Time Service classes should not depend on  Application layer classes DAO classes should only be called from  Domain classes 50
  51. 51. DEMO 51
  52. 52. Rules – Run Time Business operation retry  Caching  System Settings (using AOP)  Application Variables/Business Data (using  Annotations) 52
  53. 53. DEMO 53
  54. 54. Agenda • Domain Driven Design & Development • Spring Portfolio • Dependency Injection / AOP / Annotations • Spring Security (Demo) • Architecture Enforcement (Demo) • Code Generation (Demo) • Conclusions 54
  55. 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. 56. Code Generation Tools openArchitectureWare (oAW)  AndroMDA  Aceleo Spring Module  Skyway Builder  56
  57. 57. DEMO 57
  58. 58. Tools Spring for:  Scheduling (Quartz)  Configuration Management (Commons  Configuration, JMX) Hibernate Tools (for DDL generation)  Dozer (DO/DTO Assembly)  58
  59. 59. DDD Lifecycle Diagram Revisited 59
  60. 60. Agenda • Domain Driven Design & Development • Spring Portfolio • Dependency Injection / AOP / Annotations • Spring Security (Demo) • Architecture Enforcement (Demo) • Code Generation (Demo) • Conclusions 60
  61. 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. 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. 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. 64. Q&A 64
  65. 65. Thank You • Thank you for your attention • Feedback survey 65

×