Importance Of Being Driven

The Importance of Being Driven Antonio Terreno 2nd European Summer School on Agile Programming 28 June 2007, Varese

Software design is art
“ Software design is an art, and like any art it cannot be taught and learned as a precise science, by means of theorems and formulas.”
Floyd Marinescu

What drives you?
To finish the story?
Money?
Technology?
Design / Good code?
Arrive at 6.00 PM safe?
Career?
Doh, nothing!

The Agile Way
No upfront design, requirement gathering
The team makes the design
Participation with the stakeholder
Simple, what is simple for you?
What is good for you?
Refactoring, refactoring how? (dev skills)
Refactoring how much? (fear)

Test driven
Do I have still to talk about this?
I know you don’t like it
It makes design more complicated
1 hour to write the test, 10 seconds for the code
Do I really have to write all those tests?
It’s simple, I can do it without a test, c’mon!
I’ve done this millions of times
Why not testing after? We can have a lot of testers and they are cheaper

Behavior Driven Development
Dan North, Dave Astels
It’s not about testing, it’s about behavior
It’s about writing specifications
It’s about writing how the code works
It’s about understanding how the system works
It’s about understanding what I have to write
Unit? Unit what? The 1-1 problem
Test method names should be sentences

BDD
The given when then template
Ubiquitous language, BA, DEV, QA
Given
When
Then

BDD Tools
Tools
JBehave
NBehave
RBehave
rSpec
You can write BDD also using the old stuff, don’t worry
Code example

Domain Driven Development
Focus on the domain
A common language
Layered architecture
Entities / Value Objects
Services
Modules
Aggregates
Factories
Repositories

Domain Driven
Layered architecture
User interface
Application Layer
No business logic
No State of business objects
Holds state of an application task progress
Domain Layer
Info about the domain
State is held here
Infrastructure Layer
Communication between layers
Persistence for business objects
Support libraries

Why layers?
Manage changes
Avoids coupling of code
Avoids unexpected behaviors after changes

Entities
Objects that have an identity
Spanning the life of the system and even after
a Person object for example
The Id does never change
Some domain objects have already the concept of id
National number, airport code, …
All the domain objects are then entities?

Value Objects
When we care about what an object has and not about which object is
How and when write a VO?
First we write a VO when the object is NOT an Entity!
Will be great if a VO is immutable
For performance but mostly
They will manifest integrity
If value objects are sharable they should be immutable
Keep VO thin and simple
Please no huge VO, a VO can contain value objects and reference to Entities

Services
In the ubiquitous language the objects are the nouns, the services are the verbs.
A service provides functionality for the domain
I can’t really put this stuff on an object!
A service performs an operation
The operation refers to a domain concept
The operations refers to other object in the domain model
The operation is stateless
Keeps the domain isolated

Modules
In a complex system the model grows
Let’s split it in to modules, in order to reduce complexity
High level of cohesion, low level of coupling
Communicational cohesion
Parts of the module work with same data
Functional cohesion
Parts of the module work together to perform well-defined tasks

Aggregates
Relations between objects
One to many, many to many, complexity!
First, try to remove and refactor when you don’t need it
Try to reduce multiplicity and direction (bi to mono)
Cascade on update/delete, usually the db does this for us
Typically then what happen? Poor performances!
Use aggregate
An aggregate has an entity as root element
Only the root is obtainable through queries
The Entity is responsible of maintaining the invariants

Factories
When creating an objects instance is complex
When creating an object (especially an Aggregate) is a responsibility
Use factories.
I create the root of the Aggregate and all the contained object
Atomic creation
Factories violates objects encapsulation, be careful!
Use a constructor when:
It’s simple
All the attributes can be passed via the constructor
The class is the type, there’s no need to choose different implementation

Repositories
We don’t want to be coupled to the DB/persistence infrastructure
A repository encapsulate the logic in order to obtain object references
It may include a Strategy
It should be simple (find, add for example)
A factory creates, a repository retrieves.
A factory is pure domain, a repository communicates with the infrastructure

Refactoring
Don’t only write code, read it!
Refactoring is redesign code without changing the behavior
Do refactor when you have test coverage!
Refactoring patterns
Or refactor the domain itself ( can’t use pattern here)
Use the verbs nouns metaphor
Talk with the team
Think!
What the code does and why should be readable
Refactoring has domain motivations not only technical ones.
Including domain experts may help a lot.

All together
.

Domain Specific Languages
Small, Domain focused language
Domain experts themselves can understand, validate, modify, and often even develop DSL programs
Do I really need a new language?
Fluent interfaces
Code Example

Dev/BA
Dev pair sessions with BA
Domain Experts
Code that “even” a BA can read and change

Delivery Driven
Focus on the delivery
Focus on the after delivery
Design
Readability of the code
Layering
Tools
Continuous Integration
Techniques
Time boxing
Story Prioritization
Pairing

Importance Of Being Driven

by Antonio Terreno on Jun 29, 2007

Accessibility

Categories

Tags

Upload Details

Usage Rights

3 Embeds 4

Statistics

Importance Of Being Driven — Presentation Transcript

http://www.slideshare.net	2
http://www.techgig.com	1
http://www.soup.io	1