Agile development and domain driven design

Agile development and Domain Driven Design

Jacopo Romei
http://www.sviluppoagile.it/

Ego sliding
 Jacopo Romei
 PHP since 1999
 IT CEO in the past
 Freelance agile coach
 http://www.sviluppoagile.it/

Jacopo Romei, http://www.sviluppoagile.it/

Agile development

A family of empirical methodologies


Agile Manifesto
 Individuals over tools
 Working software over documentation
 Customer collaboration over contract deals
 Accept change over following plans


Domain

What does inspire our solutions?


Driven

Where do we find our solutions?


Design

What does provide us with solutions?


Design vs. Process
 Design principles
 Messy reality
 DDD is a way to cope with the mess
 Agile Dev is a way to cope with the mess


Manouvrability

Agility means manouvrability


Shared values
 Courage
 Respect


Shared values
 Courage  Simplicity is the art of
maximizing the amount
 Respect
of work not done
 Simplicity


Shared values
 Courage
 Respect
 Simplicity
 Communication
 Feedback


Shared values
 Courage  Who
 Respect  Which
 Simplicity  How
 Why
 Communication
 Feedback


XP and good design
 Refactoring tries to avoid overengineering
 Refactoring can develop underengineering
 XP works best with good designers
 DDD helps developers being good designers


Don't ossify, please

Supple, knowledgerich design


Orthogonality
•Orthogonality is a system design property facilitating
feasibility and compactness of complex designs.
• Orthogonality guarantees that modifying the technical
effect produced by a component of a system neither
creates nor propagates side effects to other components of
the system.
•Emergent behavior of a system should be controlled strictly
by formal definitions of its logic and not by side effects
resulting from poor integratio
•Orthogonality reduces testing and development time


Shared required practices
 Iterative and incremental development
 Close relationship with domain experts
 Refactoring


UX & Agile

Methodology to write user stories


DDD & Agile

Methodology to (let emerge) design


Ubiquitous language

One jargon to rule them all


Ubiquitous language
 Model as backbone of language in
 Code
 Diagrams
 Writings
 Speech


Ubiquitous language
 Refactor
 Classes
 Methods
 Modules
 Reflect
 Real world entities
 Confusion resolution in conversations
 Changes in language as changes in model


Example


Short example
 “If we give the Routing Service an origin,
destination and arrival time, it can look up the
stops the cargo will have to make and well... stick
them in the database”
 “The origin, destination and so on... it all feeds into
Routing Service and we get back an Itinerary
that has everything we need it”
 “A Routing Service finds an Itinerary that satisfies
a Route Specification”


Documentation

Agile methodologies value working software over
comprehensive documentation


UML is not enough
UML doesn't convoy the concepts behind a model
UML doesn't convoy what objects are meant to do


Ubiquitous documentation
UML provides some documentation
Code provides some documentation
Ubiquitous language provides some documentation


Hands-on modelers

Everyone who writes code must feel responsible for
the model.


Hands-on modelers

the model.
Everyone contributing to the model must touch the
code.


Hands-on modelers

the model.
Everyone contributing to the model must touch the
code.
That's a DDD team. That's an agile team.


Modeling paradigm

Object oriented programming is good to model the
way we think about things. OO community
developed lots of critically meaningful concepts.
PHP community: WAKE UP!


Deadly divide
 Model can be absent (brrr...)
 Model can be overdesigned
 Model can be detached from the domain
 Suspect correctness
 Hard to maintain
 Difficult to understand


Reflection

Software must reflect domain model


Ubiquity

Software must reflect ubiquitous language


Building blocks
 Layered architecture
 Services
 Entities
 Value Objects
 Factories
 Aggregates
 Repositories


Layers
 User interface
 Smart UI vs. Model Driven Design


Layers
 User interface
 Application
 a.k.a. Controller


Layers
 User interface
 Application
 Domain/Model layer


Layers
 User interface
 Application
 Domain/Model layer
 Infrastructure


Frameworks

Free choice, but domain layer must be preserved.


The end, the beginning

No one said agile was easy.
No one said it was a standalone concept.


What's next

Agile Day 2009


Jacopo Romei
jacopo [at] sviluppoagile.it
skype: jacoporomei

www.sviluppoagile.it


Agile development and domain driven design

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (15)

Similaire à Agile development and domain driven design

Similaire à Agile development and domain driven design (20)

Plus de Jacopo Romei

Plus de Jacopo Romei (20)

Dernier

Dernier (20)

Agile development and domain driven design