The Importance of Being Driven Antonio Terreno 2nd European Summer School on Agile Programming 28 June 2007, Varese
Software design is art <ul><li>“ Software design is an art, and like any art it cannot be taught and learned as a precise ...
What drives you? <ul><li>To finish the story?  </li></ul><ul><li>Money? </li></ul><ul><li>Technology? </li></ul><ul><li>De...
The Agile Way <ul><li>No upfront design, requirement gathering </li></ul><ul><li>The team makes the design </li></ul><ul><...
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>I...
Behavior Driven Development <ul><li>Dan North, Dave Astels </li></ul><ul><li>It’s not about testing, it’s about behavior <...
BDD <ul><li>The given when then template </li></ul><ul><li>Ubiquitous language, BA, DEV, QA </li></ul><ul><li>Given </li><...
BDD Tools <ul><li>Tools </li></ul><ul><ul><li>JBehave </li></ul></ul><ul><ul><li>NBehave </li></ul></ul><ul><ul><li>RBehav...
Domain Driven Development <ul><li>Focus on the domain </li></ul><ul><li>A common language </li></ul><ul><li>Layered archit...
Domain Driven <ul><li>Layered architecture </li></ul><ul><ul><li>User interface </li></ul></ul><ul><ul><li>Application Lay...
Why layers? <ul><li>Manage changes </li></ul><ul><li>Avoids coupling of code </li></ul><ul><li>Avoids unexpected behaviors...
Entities <ul><li>Objects that have an identity </li></ul><ul><li>Spanning the life of the system and even after </li></ul>...
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...
Services <ul><li>In the ubiquitous language the objects are  the nouns, the services are the verbs.  </li></ul><ul><li>A s...
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...
Aggregates <ul><li>Relations between objects </li></ul><ul><ul><li>One to many, many to many, complexity! </li></ul></ul><...
Factories <ul><li>When creating an objects instance is complex </li></ul><ul><li>When creating an object (especially an Ag...
Repositories <ul><li>We don’t want to be coupled to the DB/persistence infrastructure </li></ul><ul><ul><li>A repository e...
Refactoring <ul><li>Don’t only write code, read it! </li></ul><ul><li>Refactoring is redesign code without changing the be...
All together <ul><li>. </li></ul>
Domain Specific Languages <ul><li>Small, Domain focused language  </li></ul><ul><li>Domain experts themselves can understa...
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...
Delivery Driven <ul><li>Focus on the delivery </li></ul><ul><li>Focus on the after delivery </li></ul><ul><ul><li>Design <...
Upcoming SlideShare
Loading in...5
×

Importance Of Being Driven

1,985

Published on

The importance to be Driven

There are many buzzwords and acronyms to describe how the software should be designed. TDD (Test Driven), BDD (Behaviour Driven), DDD (Domain Driven) are the most well known. In this speech we'll run thought all these techniques comparing each one of those with TDD and finding what are the common concepts. An exercise will show to the students how different the code will be using different design methodologies as driver.

Published in: Technology
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,985
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
0
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

Transcript of "Importance Of Being Driven"

  1. 1. The Importance of Being Driven Antonio Terreno 2nd European Summer School on Agile Programming 28 June 2007, Varese
  2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 20. All together <ul><li>. </li></ul>
  21. 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. 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. 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>

×