Your SlideShare is downloading. ×
0
Closing the Gap - DDD, MDD, DCI and Codegeneration
Closing the Gap - DDD, MDD, DCI and Codegeneration
Closing the Gap - DDD, MDD, DCI and Codegeneration
Closing the Gap - DDD, MDD, DCI and Codegeneration
Closing the Gap - DDD, MDD, DCI and Codegeneration
Closing the Gap - DDD, MDD, DCI and Codegeneration
Closing the Gap - DDD, MDD, DCI and Codegeneration
Closing the Gap - DDD, MDD, DCI and Codegeneration
Closing the Gap - DDD, MDD, DCI and Codegeneration
Closing the Gap - DDD, MDD, DCI and Codegeneration
Closing the Gap - DDD, MDD, DCI and Codegeneration
Closing the Gap - DDD, MDD, DCI and Codegeneration
Closing the Gap - DDD, MDD, DCI and Codegeneration
Closing the Gap - DDD, MDD, DCI and Codegeneration
Closing the Gap - DDD, MDD, DCI and Codegeneration
Closing the Gap - DDD, MDD, DCI and Codegeneration
Closing the Gap - DDD, MDD, DCI and Codegeneration
Closing the Gap - DDD, MDD, DCI and Codegeneration
Closing the Gap - DDD, MDD, DCI and Codegeneration
Closing the Gap - DDD, MDD, DCI and Codegeneration
Closing the Gap - DDD, MDD, DCI and Codegeneration
Closing the Gap - DDD, MDD, DCI and Codegeneration
Closing the Gap - DDD, MDD, DCI and Codegeneration
Closing the Gap - DDD, MDD, DCI and Codegeneration
Closing the Gap - DDD, MDD, DCI and Codegeneration
Closing the Gap - DDD, MDD, DCI and Codegeneration
Closing the Gap - DDD, MDD, DCI and Codegeneration
Closing the Gap - DDD, MDD, DCI and Codegeneration
Closing the Gap - DDD, MDD, DCI and Codegeneration
Closing the Gap - DDD, MDD, DCI and Codegeneration
Closing the Gap - DDD, MDD, DCI and Codegeneration
Closing the Gap - DDD, MDD, DCI and Codegeneration
Closing the Gap - DDD, MDD, DCI and Codegeneration
Closing the Gap - DDD, MDD, DCI and Codegeneration
Closing the Gap - DDD, MDD, DCI and Codegeneration
Closing the Gap - DDD, MDD, DCI and Codegeneration
Closing the Gap - DDD, MDD, DCI and Codegeneration
Closing the Gap - DDD, MDD, DCI and Codegeneration
Closing the Gap - DDD, MDD, DCI and Codegeneration
Closing the Gap - DDD, MDD, DCI and Codegeneration
Closing the Gap - DDD, MDD, DCI and Codegeneration
Closing the Gap - DDD, MDD, DCI and Codegeneration
Closing the Gap - DDD, MDD, DCI and Codegeneration
Closing the Gap - DDD, MDD, DCI and Codegeneration
Closing the Gap - DDD, MDD, DCI and Codegeneration
Closing the Gap - DDD, MDD, DCI and Codegeneration
Closing the Gap - DDD, MDD, DCI and Codegeneration
Closing the Gap - DDD, MDD, DCI and Codegeneration
Closing the Gap - DDD, MDD, DCI and Codegeneration
Closing the Gap - DDD, MDD, DCI and Codegeneration
Closing the Gap - DDD, MDD, DCI and Codegeneration
Closing the Gap - DDD, MDD, DCI and Codegeneration
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Closing the Gap - DDD, MDD, DCI and Codegeneration

3,979

Published on

How do we close the gap between developers, management and the business experts. After introducing typical management thinking and the problems this presents, I will introduce how I believe we can try …

How do we close the gap between developers, management and the business experts. After introducing typical management thinking and the problems this presents, I will introduce how I believe we can try to immunize ourselves from the things that are bound to change during a project. This includes Agile & Lean practices, Domain Driven Design (DDD), Model Driven Development (MDD) and Data Context Interaction (DCI).

1 Comment
12 Likes
Statistics
Notes
No Downloads
Views
Total Views
3,979
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
99
Comments
1
Likes
12
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • E.g.: We want reuse – hence we need SOA and an ESB and then things will magically start working and we will have reuse – aka. The magic silverbullet
  • *Up to 10 developers –Nextjump to increase efficiency is 30 devs – next jump again is 100 devs*Typical developer estimates are multiplied by a factor of 3 to 6 to give the actual time spent
  • Skill: We all need to become more professional. Management needs to understand what they’re trying to manage and developers need to give proper feedback and not only resort to complaining or choosing framework/tools for the fun of it Less CV driven developmentClose contract: Walk the talkAutomation: Continuous Integration, Testing, Deployment, Code generation
  • Why do all project almost always start from scratch – beginning with a clean plate and creating a new architecture – where’s the momentum and gathering of learning's from previous projects?
  • Domain Entities, Processes, UI’s
  • [Mapped Super Class]^[Abstract A{bg:orange}], [Mapped Super Class]^[Abstract B{bg:orange}],[Abstract B]++->[A], [Abstract A]+->[B], [Abstract A]^[A], [Abstract B]^[B]
  • Transcript

    • 1. Closing the Gap
      Copenhagen .NET User Group – 23. February 2011
      Jeppe Cramon
    • 2. What’s the current status in our work environment?
    • 3. Typical management thinking
      We pick the tools and architecture that Gartner recommends
      More people working on a project = The faster it gets finished
      100 foreign developers are better than 10 local, if the price is the same
    • 4.
    • 5. The problem with AMAG*
      Management picks what Gartner recommends and feel justified (CMA**)
      Don’t have to understand anything related to development
      Too many silver bullets and magic formulas
      Developers gets a tool, but not necessarily the right tool for the job
      AMAG* Architecture by Management, Approved by Gartner
      CMA** Cover my Ass
    • 6. 9 women can deliver a baby in 1 month
      Increasing the number of developers on a project, decreases developer efficiency
      Communication overhead
      More ceremony (Documents and Processes)
      Writing code typically only amounts to 25-30% of the total project time
    • 7. Closing the Gap
      We need:
      Smaller teams (5-10 people)
      What if instead of "what languages work for large teams" we looked for "what languages prevent the need for large teams?” – Greg Young
      More skilled developers and managers
      Close contact to Product owner and Business Experts
      Higher level of Abstraction
      High degree of Automation
      Shorter feedback cycles
      Make it cheaper to make mistakes and learn from it
    • 8. What’s this talk about?
      I will give my experience of how to close the gap as a developer & architect
    • 9. We can’t control everything
      But we can try to immunize ourselves from changes that we know will occur
    • 10. Combine Lean & Agile
    • 11. Lean
      A little thinking ahead can save you a lot of pain down the road
      Architectural refactoring is expensive
      Understand the nature of your domain
      To pick the right abstractions
      Discover patterns & variations
      Do enough upfront – but not too much!
      Focus on learning and improving
      Reducing waste
      Why do most projects always start from scratch?
    • 12. Example
      WHEN BUILDING
      A LIFE INSURANCE APPLICATION
      DEAL WITH TEMPORAL DESIGN
      UPFRONT
    • 13. Agile
      Apply your learning's iteratively – It’s the least expensive way
      Pick the right tools for the right job
      Use proper test approaches to ensure quality.
      This helps you discover when new learning’s break old assumptions
      Focus on importance and criticality
    • 14. Where do we start?
    • 15. How to get a grasp of the unknown
      Talk the talk – learn the language of the domain experts
      Forming our Ubiquitous Language
      Draw a lot of paper sketches
      Domain Entities (Models), Processes, UI’s
    • 16. Models -the backbone of Domain Driven Design (DDD)
      They give us our common language – the ubiquitous language
      Are a great tool for communication
      Clearly defines boundaries and help us grasp a complex world
    • 17. Core Principles of DDD
      The Model and the Design shape each other
      The binding between Model and implementation, makes the model relevant
      The analysis that went into the Model applies to the final product the running program
      The Model is the backbone of the Ubiquitous language – used by all team members.
      Closing the Gap – developers talk to business experts without translation
      The Model is distilled knowledge – Captures how we choose to think about the domain in form of: terms, concepts and the relationship between them
      The Model isn’t about realism – “Even in a domain of real-world things, our domain model is artificial creation, like movie making…”
    • 18. Core patterns
      Repositories
      ENTITIES
      Factories
      Layered Architecture
      VALUE OBJECTS
      Modules
      Services
      AGGREGATES
    • 19. Entities
      Motivators:
      Objects are defined by identity and not by their attributes.
      May have lifecycle, can change form by time and context (A Person that becomes a father, which becomes a grand father, etc.)
      Focus is on Whoand not on what!
    • 20. Value Objects
      Motivators:
      Objects which describe thingsand are defined by their attributes (not by their identity) and doesn’t have a lifecycle.
      Focus is on What and not on who!
    • 21. Aggregates
      What:
      • Cluster coherent Entities and Value Objects, with complex associations, in to aggregates with well defined boundaries.
      • 22. Choose one entity to be root and controlaccess to objects inside the boundary through the root.
      • 23. External objects hold references to the root
      Motivation:
      Control invariants and consistency through the aggregate root.
      Enables: Loading schemes, coarse grained locking, consistency boundaries for DDDD
    • 24. So now that we have a model sketch – what’s next?
    • 25. Same procedure as last year?
      We write our ORM classes and mapping by hand
    • 26. So we go from
    • 27. To…By writing
      package dk.tigerteam.mdsd.demo.model.internal;
      @Entity
      @Table(name = "Customer")
      public class Customer extends AbstractEntity{
      private static final long serialVersionUID = 2098912667L;
      @Basic
      @Column(name = "name", nullable = false)
      private String name;
      @OneToOne(cascade = {
      CascadeType.MERGE, CascadeType.PERSIST, CascadeType.REFRESH},
      fetch = FetchType.LAZY)
      @JoinColumn(name = "addressId")
      @NotNull
      private dk.tigerteam.mdsd.demo.model.internal.Address address;
      @OneToMany(cascade = {
      CascadeType.MERGE, CascadeType.PERSIST, CascadeType.REFRESH},
      targetEntity= Booking.class, mappedBy = "customer",
      fetch = FetchType.LAZY)
      private Set<Booking> bookingCollection =
      new java.util.HashSet<Booking>();
      public String getName() {
      return name;
      }
      public void setName(String name) {
      this.name = name;
      }










      }
      package dk.tigerteam.mdsd.demo.mode.internal;
      @Entity
      @Table(name = "Booking")
      public class Booking extends AbstractEntity {
      private static final long serialVersionUID = 170080605L;
      @Basic
      @Column(name = "comment", nullable = false)
      private String comment;
      @Basic
      @Temporal(TemporalType.TIMESTAMP)
      @Column(name = "time", nullable = false)
      private java.util.Date time;
      @Basic
      @Column(name = "timeslot", nullable = false)
      private int timeslot;
      @ManyToOne(cascade = {
      CascadeType.MERGE, CascadeType.PERSIST, CascadeType.REFRESH},
      fetch = FetchType.LAZY)
      @JoinColumn(nullable = false, name = "customerId")
      private Customer customer;
      public String getComment() {
      return comment;
      }
      public void setComment(String parameter) {
      this.comment = parameter;
      }
      public java.util.DategetTime() {
      return time;
      }







      }
      @Entity
      @Table(name = "Address")
      public class Address extends AbstractEntity {
      private static final long serialVersionUID = 1697028161L;
      @Basic
      @Column(name = "street", nullable = false)
      private String street;
      @Basic
      @Column(name = "zipCode", nullable = false)
      private String zipCode;
      @Basic
      @Column(name = "city", nullable = false)
      private String city;
      public String getStreet() {
      return street;
      }
      public void setStreet(String parameter) {
      this.street = parameter;
      }



      }
    • 28. This works fairly well, until…
      • We get tired of writing the same tedious code by hand
      • 29. We suddenly realize that:
      • 30. Our assumptions didn’t hold up and we need to change many of our mappings
      • 31. We need to write a lot of test code to ensure that our mappings are correct
      • 32. We’re writing a lot of technical code and very little business code
    • Also
      Who maintains the models as the code changes?
    • 33. So what is the solution?
      A “radical” shift – to a larger degree of automation

      Model Driven Development
    • 34. Get rid of tedious repetitive code
      Model
      Generator
      Frameworks
      (Hibernate/JPA, Entity Framework)
      Schematic code
      Interesting code
      (Hand written)
      Hand written
      Libraries (e.g. Java/.NET)
    • 35. Let’s get cranking with UMLand TigerMDSD
    • 36. The process


      Java/C# code
      JPA / Entity Framework
      DB schemas
      WSDL
      XML Schema
      Integration tests
      TigerMDSD
      MODEL is KING
    • 37. What’s possible with the Meta Model
      Just about everything -
      Set your mind free 
    • 38. What about Domain Logic?
      It’s important to separate Entity Logic and Use Case Logic
      Use Case Logic doesn’t belong in Entities (violates coherence)
    • 39. Domain Modeling
      Domain Object design should focus on WHAT the SYSTEM IS
      NOT on what the system DOES
      James Coplien – DCI Talk at Öredev 2009
    • 40. Entity Logic
      We have several options with regards to Entity Logic
      Optional

      What we model
      Alternatives:
      • Mixins / Traits
      • 41. Extension Methods
      • 42. Priviledged Aspects
      • 43. Protected Regions
      Partial classes
      3 level inheritance
    • 44. DCI
      Allows us to separate Form
      What the System IS – AKA. The domain mode
      from Structure
      What the System DOES
      Identifying that Form changes much slower than the Structure
    • 45. Use Case Logic
      This type of logic spans Domain Objects.
      Data Context Interaction (DCI) offers a very flexible way of handling this complexity, by allowing Domain Objects to play different Roles within different Contexts (Use cases)
    • 46. DCI
      Separating Structure from Form is done using Roles, which are (typically) played by Domain Objects
      Mixins/Traits/Partial Classes/Extension Methods are used to enhance Domain Objects with extra functionality (Role Methods) within a Context
    • 47. DCI
      Marriage Context
      Role Map
      Interaction
      Mother
      Person
      ID: 2
      Son
      Father
      Person
      ID: 3
      Person
      ID: 1
    • 48. Higher abstraction level
      Bi-temporal history
      At any time
      Over a long period
      Gives us the freedom
      to chose the right implementation
      without revealing it in the model
      What we model
      <<History>>
    • 49. Versioning (Temporal Object Pattern)
    • 50. Generating WebServices
    • 51. Example Extensions
      Built-in Types
      Bidirectional associations
      Property Sugar methods
      Get Or New Property methods
      Constructor (immutable properties)
      Class Hierarchy Java doc generator
      Serial Version UID generator
      MetaType Java doc generator
      SerializablePojo’s
      ToString/Equals/HashCode



      JPA Field based persistence
      JPA Named Tables and Columns
      JPA OptimisticLocking exceptions
      Hibernate Foreignkey Constraints
      Hibernate Foreignkey Index
      Hibernate Fetch Optimization
      Hibernate Association Unproxying
      Hibernate Table Comments
      Hibernate HH-3544 bug fix
    • 52. The Core of Flexible Code Generator
    • 53. Model Transformation
    • 54. Code DOM
    • 55. An Event Based Extension Model
    • 56. Extensions
    • 57. Example Extension
    • 58. Example Extension - continued
    • 59. A little statistics
      Source: http://modelseverywhere.wordpress.com/2010/12/20/more-technology-adoption-curves/
    • 60. Thanks
      For more information
      jeppe@tigerteam.dk
      or
      @jeppec on Twitter

    ×