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

Closing the Gap - DDD, MDD, DCI and Codegeneration

on

  • 3,816 views

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

Statistics

Views

Total Views
3,816
Views on SlideShare
3,810
Embed Views
6

Actions

Likes
9
Downloads
85
Comments
1

2 Embeds 6

https://www.linkedin.com 5
http://www.slashdocs.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • 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]

Closing the Gap - DDD, MDD, DCI and Codegeneration Closing the Gap - DDD, MDD, DCI and Codegeneration Presentation Transcript

  • Closing the Gap
    Copenhagen .NET User Group – 23. February 2011
    Jeppe Cramon
  • What’s the current status in our work environment?
  • 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
  • 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
  • 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
  • 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
  • What’s this talk about?
    I will give my experience of how to close the gap as a developer & architect
  • We can’t control everything
    But we can try to immunize ourselves from changes that we know will occur
  • Combine Lean & Agile
  • 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?
  • Example
    WHEN BUILDING
    A LIFE INSURANCE APPLICATION
    DEAL WITH TEMPORAL DESIGN
    UPFRONT
  • 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
  • Where do we start?
  • 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
  • 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
  • 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…”
  • Core patterns
    Repositories
    ENTITIES
    Factories
    Layered Architecture
    VALUE OBJECTS
    Modules
    Services
    AGGREGATES
  • 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!
  • 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!
  • Aggregates
    What:
    • Cluster coherent Entities and Value Objects, with complex associations, in to aggregates with well defined boundaries.
    • Choose one entity to be root and controlaccess to objects inside the boundary through the root.
    • 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
  • So now that we have a model sketch – what’s next?
  • Same procedure as last year?
    We write our ORM classes and mapping by hand
  • So we go from
  • 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;
    }



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

    Model Driven Development
  • 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)
  • Let’s get cranking with UMLand TigerMDSD
  • The process


    Java/C# code
    JPA / Entity Framework
    DB schemas
    WSDL
    XML Schema
    Integration tests
    TigerMDSD
    MODEL is KING
  • What’s possible with the Meta Model
    Just about everything -
    Set your mind free 
  • 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)
  • 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
  • Entity Logic
    We have several options with regards to Entity Logic
    Optional

    What we model
    Alternatives:
    • Mixins / Traits
    • Extension Methods
    • Priviledged Aspects
    • Protected Regions
    Partial classes
    3 level inheritance
  • 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
  • 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)
  • 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
  • DCI
    Marriage Context
    Role Map
    Interaction
    Mother
    Person
    ID: 2
    Son
    Father
    Person
    ID: 3
    Person
    ID: 1
  • 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>>
  • Versioning (Temporal Object Pattern)
  • Generating WebServices
  • 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
  • The Core of Flexible Code Generator
  • Model Transformation
  • Code DOM
  • An Event Based Extension Model
  • Extensions
  • Example Extension
  • Example Extension - continued
  • A little statistics
    Source: http://modelseverywhere.wordpress.com/2010/12/20/more-technology-adoption-curves/
  • Thanks
    For more information
    jeppe@tigerteam.dk
    or
    @jeppec on Twitter