The document discusses the importance of being driven in software design, emphasizing that it is an art that cannot be rigorously taught. It covers key concepts like Agile methodologies, Behavior Driven Development (BDD), Domain Driven Development, and the significance of refactoring and maintaining a clear domain language. The text also highlights the role of factories and repositories in managing object creation and data retrieval, advocating for a collaborative approach involving domain experts to enhance code readability and alignment with business needs.

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

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

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

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)

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

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

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

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

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

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

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

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?

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

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

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

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

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

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

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.

20. All together .

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

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

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