Closing the Gap - DDD, MDD, DCI and Codegeneration

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 = {
targetEntity= Booking.class, mappedBy = "customer",
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 {
@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 = {
@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 {
@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

Closing the Gap - DDD, MDD, DCI and Codegeneration

by Jeppe Cramon

Accessibility

Upload Details

Usage Rights

Statistics

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