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

2.
Software design is art <ul><li>“ 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.” </li></ul><ul><li>Floyd Marinescu </li></ul>

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

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

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

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

7.
BDD <ul><li>The given when then template </li></ul><ul><li>Ubiquitous language, BA, DEV, QA </li></ul><ul><li>Given </li></ul><ul><li>When </li></ul><ul><li>Then </li></ul>

8.
BDD Tools <ul><li>Tools </li></ul><ul><ul><li>JBehave </li></ul></ul><ul><ul><li>NBehave </li></ul></ul><ul><ul><li>RBehave </li></ul></ul><ul><ul><li>rSpec </li></ul></ul><ul><ul><li>You can write BDD also using the old stuff, don’t worry </li></ul></ul><ul><li>Code example </li></ul>

9.
Domain Driven Development <ul><li>Focus on the domain </li></ul><ul><li>A common language </li></ul><ul><li>Layered architecture </li></ul><ul><li>Entities / Value Objects </li></ul><ul><li>Services </li></ul><ul><li>Modules </li></ul><ul><li>Aggregates </li></ul><ul><li>Factories </li></ul><ul><li>Repositories </li></ul>

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

11.
Why layers? <ul><li>Manage changes </li></ul><ul><li>Avoids coupling of code </li></ul><ul><li>Avoids unexpected behaviors after changes </li></ul>

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

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

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

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

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

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

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

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

20.
All together <ul><li>. </li></ul>

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

22.
Dev/BA <ul><li>Dev pair sessions with BA </li></ul><ul><li>Domain Experts </li></ul><ul><li>Code that “even” a BA can read and change </li></ul>

23.
Delivery Driven <ul><li>Focus on the delivery </li></ul><ul><li>Focus on the after delivery </li></ul><ul><ul><li>Design </li></ul></ul><ul><ul><li>Readability of the code </li></ul></ul><ul><ul><li>Layering </li></ul></ul><ul><li>Tools </li></ul><ul><ul><li>Continuous Integration </li></ul></ul><ul><li>Techniques </li></ul><ul><ul><li>Time boxing </li></ul></ul><ul><ul><li>Story Prioritization </li></ul></ul><ul><ul><li>Pairing </li></ul></ul>