Closing the Gap

Danish Agile User Group – 3. March 2011

Jeppe Cramon

WHAT’S THE CURRENT STATUS IN OUR WORK ENVIRONMENT?

Overheard in real projects• “We freeze the database design 3 months before go-live”• “The customer can’t get that, because then we’ll have to rewrite

too much”• “Why isn’t the documentation updated?”• “Who can work this weekend? We need to rewrite History on all

Entities”• “We’ll do like this now, and then change when we have more

time”• “We just need more people!”

What about management?

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 GartnerCMA** 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 GapWe 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?

ExampleWHEN 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 unknownTalk the talk – learn the language of the domain experts

Draw a lot of paper sketches

Forming our Ubiquitous Language

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 DDD1. The Model and the Design shape each other2. The binding between Model and implementation, makes the model

relevant3. The analysis that went into the Model applies to the final product the

running program4. The Model is the backbone of the Ubiquitous language – used by all team

members. 5. Closing the Gap – developers talk to business experts without translation6. The Model is distilled knowledge – Captures how we choose to think about

the domain in form of: terms, concepts and the relationship between them7. 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

ENTITIES

VALUE OBJECTS

AGGREGATES

Modu

les

Layere

d A

rch

itect

ure

Fact

ori

es

Rep

osi

tori

es

Serv

ices

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 Who and not on what!

Value Objects

Motivators:Objects which describe things and 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 control access 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

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.Date getTime() { 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; } … … …}

To…By writing

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 similar technical code and very little business code (DRY)

STOOOOOOOOOP !!!!!!!• We’re painting ourselves into a corner!• We don’t update the models or the

documentation• We code from exceptions and not rules• We tend to forget the customer and their needs• We handle symptoms, rather than doing the right

thing

So what is the solution?A “radical” shift – to a larger degree of automation

Model Driven Development

Get rid of tedious repetitive code

Frameworks

(Hibernate/JPA, Entity

Framework)

Libraries (e.g. Java/.NET)

Schematic code

Interesting code(Hand written)

Hand written

Model Generator

Let’s get cranking with UMLand TigerMDSD

The process

Java/C# codeJPA / Entity FrameworkDB schemasWSDLXML SchemaIntegration 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 DOESJames Coplien – DCI Talk at Öredev 2009

Entity LogicWe have several options with regards to Entity Logic

What we model

Partial classes3 level inheritance

Alternatives:• Mixins / Traits• Extension Methods• Priviledged Aspects• Protected Regions

Optional

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

DCIMarriage Context

PersonID: 3

PersonID: 1

PersonID: 2

Role Object

Father Object ID: 1

Mother Object ID: 2

Son Object ID: 3Mother

SonFather

Role Map

Interaction

Higher abstraction levelBi-temporal history

At any time

Over a long period

What we model

<<History>>

Gives us the freedomto chose the right implementationwithout revealing it in the model

Generating WebServices

A little statistics

Source: http://modelseverywhere.wordpress.com/2010/12/20/more-technology-adoption-curves/

Positive Side-effects of MDD• Better and more coherent quality• Model Documentation is always up-to-date• Closer to the customer – speak the same language• Fewer resources – better economy• Removes focus from technical mumbo-jumbo• Automation of tests• Easier to follow progress

Challenges with MDD• New way of thinking and working• This is NOT Case Tools re-invented!• Parallel development (Branching & Merging requires

proper tool support)• Handling new production releases requires tool support for

updating databases, etc.• The Ketchup effect – Don’t forget it’s iterative• Model is KING

References• BEC Pension• Letpension• Elektronisk Tinglysning (CSC)• Miracle A/S• PFA Pension• …

ThanksFor more information

jeppe@tigerteam.dk

or

@jeppec on Twitter