Closing the Gap Danish Agile User Group – 3. March 2011 Jeppe Cramon
Jan 15, 2015
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• …