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

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

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• Serializable Pojo’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/

ThanksFor more information

jeppe@tigerteam.dk

or

@jeppec on Twitter