Slideshare.net (beta)

Slide 1: The Importance of Being Driven Antonio Terreno 2nd European Summer School on Agile Programming 28 June 2007, Varese © ThoughtWorks, 2006

Slide 2: 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 © ThoughtWorks, 2007

Slide 3: What drives you? • To finish the story? • Money? • Technology? • Design / Good code? • Arrive at 6.00 PM safe? • Career? • Doh, nothing! © ThoughtWorks, 2007

Slide 4: 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) © ThoughtWorks, 2007

Slide 5: 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 © ThoughtWorks, 2007

Slide 6: 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 © ThoughtWorks, 2007

Slide 7: BDD • The given when then template • Ubiquitous language, BA, DEV, QA • Given • When • Then © ThoughtWorks, 2007

Slide 8: BDD Tools • Tools – JBehave – NBehave – RBehave – rSpec – You can write BDD also using the old stuff, don’t worry • Code example © ThoughtWorks, 2007

Slide 9: Domain Driven Development • Focus on the domain • A common language • Layered architecture • Entities / Value Objects • Services • Modules • Aggregates • Factories • Repositories © ThoughtWorks, 2007

Slide 10: 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 © ThoughtWorks, 2007

Slide 11: Why layers? • Manage changes • Avoids coupling of code • Avoids unexpected behaviors after changes © ThoughtWorks, 2007

Slide 12: 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? © ThoughtWorks, 2007

Slide 13: 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 © ThoughtWorks, 2007

Slide 14: 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 © ThoughtWorks, 2007

Slide 15: 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 © ThoughtWorks, 2007

Slide 16: 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 © ThoughtWorks, 2007

Slide 17: 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 © ThoughtWorks, 2007

Slide 18: 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 © ThoughtWorks, 2007

Slide 19: 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. © ThoughtWorks, 2007

Slide 20: All together . © ThoughtWorks, 2007

Slide 21: 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 © ThoughtWorks, 2007

Slide 22: Dev/BA • Dev pair sessions with BA • Domain Experts • Code that “even” a BA can read and change © ThoughtWorks, 2007

Slide 23: 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 © ThoughtWorks, 2007