A deep dive into TDD, BDD, DDD, design patterns and design principles.

1. Dennis Doomenft. Jonne Kats & Peter Hesseling Software Development Practices in Practice

2. 09:00 – 10:15Iteration 110:30 – 12:00 Iteration 212:00 – 13:00 Lunch13:00 – 14:15 Iteration 314:30 – 15:45 Iteration 416:00 – 17:00 Iteration 5 Agenda Product Backlog Aspects of Software Quality The Demo Case Acceptance Testing Domain Driven Design Automatic Testing Test Driven Development Mocking RefactoringPerformance Testing Behavior Driven Development Design Principles & Patterns Clean Code CQRS

3. Orthogonal Reversibility Feedback Iterative Development Minimal Duplication Aspects of software quality

4. Use Evolutionary Design & Reference Architecture Treat your code as a book Always check-in with better quality (!= software rot) Adhere to Clean Code Use Coding Guidelines Prevent duplication The Golden Rules

5. Don't forget YAGNI Don't make assumptions on legacy code Use TDD or BDD Consider using DDD if applicable Refactor aggressively Design towards patterns More Golden Rules

6. The Kitchen

7. Acceptance Testing Driven Development Jonne Kats

8. Breaks a complex domain into small chunks Uses highly expressive models (typically UML sketches) Intimately involves business Understandable by everyone Promotes a loosely coupled design Provides guidelines for large organizations Domain Driven Design

9. Ubiquitous Language One common unambiguous language Includes concepts and verbs Ensures collaborate understanding of the domain Originates from business Maintain a glossary (incl. translations) Apply to everything; code, tests, UI When refactoring, refactor everything Domain Driven Design

10. Entity Has identity in domain Identity never changes Enforces business rules on its properties Is not directly accessible Often has a functional identifier Domain Driven Design

11. Value Object No identity, just lightweight data Immutable Behaves like a primitive type Often reusable Examples: TimeFrame, ISBN, PostalCode, Email, Address Domain Driven Design

12. Aggregate Closely related entities and value objects Has global identity Only accessed through its Aggregate Root entity Ensures integrity of all entities Typically loaded and saved as one unit Loaded using a repository and (often) created using a factory Deleting the root, deletes everything in the aggregate Domain Driven Design

13. Domain Services Stateless Often the entry point into the model Enforce rules on multiple aggregates Implemented as methods or Commands Domain Driven Design

14. Strategic Design Bounded Contexts Context Maps Shared Kernel Customer/supplier development teams Conformist Anti-corruption layer Separate Ways Domain Driven Design

15. Unit Tests Fast in-memory tests Independent of any resources Integration Tests Access databases, files, services, I/O End-2-End Tests Full tests including all related systems Automated Testing

16. Small and focused Intention revealing Repeatable Have no side-effects Independent Have a clear name Tests should be...

17. It is important not to show what is not important Use Object Mother or Test Data Builder Signal the importance of variables using 'a', 'the', 'some‘ Start small Test what you know now (and assemble the rest) Guidelines for testing

18. Isolate The Ugly Stuff Use Dependency Injection Prefer state-based tests Test one condition Guidelines for testing

19. Is a design process Great for quality tests Tests are your first users Can be your documentation If TDD hurts => you're doing it wrong Red-Green-Refactor Better for state-based tests Test Driven Development 28 May 2009 Dennis Doomen

20. Design Effects More client control More interfaces/factories More focused Less coupling Problems UI Persistent Data False sense of security Losing the overview More code to maintain Test Driven Development

21. Stubs are stand-ins with fixed values Mocks can be used for expectations Frameworks: Rhino Mocks, NMock, MOQ, TypeMock (commercial) Guidelines Don't mock chatty interfaces Don't have more than 2-3 mocks per test Only mock your nearest neigbors Mocking 28 May 2009 Dennis Doomen

22. Karl Seguin wrote: Refusing Getting too excited Testing everything! Integration testing Discover mocking Mocking everything Becoming effective Phases of automated testing 28 May 2009 Dennis Doomen

23. Safe Delete Encapsulate Field Use Base Type where Possible Replace Constructor with Factory Method Convert Extension Method to Plain Static (vv) Convert Method to Property (vv) Convert Property to Auto-Property Extract Class from Parameters Rename Member / Type Rename / Move Namespace Extract Interface / Method / Superclass Pull Up & Down Introduce Field, Variable or Parameter Move To File (in Folder) Change Signature Refactoring

24. Performance Testing Peter Hesseling

25. Flows naturally from user storiesAs a...I want...so that into Given...when...then More behavior oriented ‘TDD Done Right’ Great for exploring the Ubiquitous Language using exploratory specs Seems easier to start with More intention revealing Difficult to implement with MSTest No single framework (yet) Behavior Driven Development

26. MSpec 0.3 Behavior Driven Development

27. Subspec Behavior Driven Development

28. The Kitchen Reference Architecture Dennis Doomen Application Shell Silverlight 4 Views (XAML + C#) DI MVVM Support View Models Commands Controller Kitchen Context Application Services Unity for SL DTOs WCF RIA Services Enterprise Library Kitchen Service Domain Model Domain Events Domain Services Translation Policy Injection Validation Logging DI NHibernate(+ Fluent & LINQ) Service Agents Unit of Work Repositories AutoMapper Database Backoffice Systems

29. The Principle of Least Surprise Single Responsiblity Principle Open Closed Principle Liskov Substitution Principle Interface Seggregation Principle Dependency Inversion Principle Law of Demeter (a.k.a. Writing Shy Code) Command Query Separation Design Principles

30. Patterns

31. Communicate design Solve common challenges Promote object-oriented design Promote loose coupling and reuse Go hand in hand with S.O.L.I.D. Purpose of Patterns

32. Technical Patternssingleton, factory, adapter, chain of responsibility, strategy, state, bridge, proxy, command, interpreter, mediator, memento, observer, template, composite Architectural PatternsCQRS, layer supertype, SOA, MVC, MVP, PM, Pipes & Filters, Patterns Examples

33. Domain Patternsdomain model, transaction script, business actions, entity factory, repository, entity, value object, aggregate, domain service, domain events, specification, query objects Strategic PatternsShared Kernel, Customer/Supplier, Conformist, Anti-Coruption Layer, Separate Ways Patterns Examples

34. Gregg Irwin said: You use it without being aware You hear about it, read up on it, and tinker a bit You learn more and start using it explicitly, if naïvely You get the fire and evangelize Something "clicks" You learn more and apply it "less naïvely" and more implicitly Time passes and you see flaws You question the concept (often because you misapplied it) You either forget about it or add knowledge and experience You use it without being aware that you're using it Phases of Pattern Adoption

35. Only if the data and actions are available in all states! State Pattern

36. Domain Event Pattern

37. Query-by-Example Query Object Specification LINQ Query Patterns

38. Used in WCSF Many interaction tests Requires a lot of mocking Strong view control Model View Presenter

39. Few interaction tests Many state-based tests Requires less mocking No view control Presentation Model

40. Microsoft variant of PM Easy data binding Bi-directional synchronization Model View View-Model

41. Responsibilities Hides access to the DB Behaves like a collection (implements ICollection<T>) Could support Transparent Persistency Lazy loading Automatic flushing Provides optimizations such as caching Provides exception shielding Repository Pattern

42. Recommendations Use an ORM such as NHibernate, Entity Framework or LLGenPro One repository per DDD aggregate root Use interfaces to allow faking/stubing Implement IQueryable (LINQ) Use Query Object or Specification patterns Repository Pattern

43. Responsibilities Encapsulate peculiars of external systems Reduces impact of changes Facilitate single sign-on Caching Resistant against temporary network problems Monitoring and tracing Service Agents

44. Recommendations Use interfaces to enable mocking/stubbing Use service agents for reporting servers and/of file I/O Use a workflow Service Agents

45. Clean Code

46. Smells Too many, output or flag arguments Inline Comments not related to a complex algorithm Dead Code Inconsistency (solve similar problems with similar solutions) Artificial Coupling Obscured Intent Misplaced Responsibility Clean Code

47. Guidelines Functions Names Should Say What They Do and Should Do One Thing and be short One Switch To Rule Them All (!) Be Precise Don' Mix Levels of Abstractions Always treat warnings as errors Clean Code

48. Case Study The Kitchen

49. US01 - Als kok wil ik recepten kunnen bijhouden met titel, beschrijving, instructies, bereidingstijd, ingredienten en moeilijkheidsgraad. US02 - Als kok wil ik kunnen zien wat de kosten van een recept bij benadering zijn (op basis van de productprijzen) US03 - Als kok wil ik per eter een profiel kunnen bijhouden met naam, adres, telefoonummer en adresgegevens. US 04 - Als kok wil ik per eter kunnen aangeven of een eter allergisch is, dat product niet lust, of liever niet eet US05 - Als kok wil ik een boodschappenlijstje kunnen genereren o.b.v. een of meerdere recepten. User Stories Dennis Doomen

50. US06 - Als kok wil ik de boodschappen kunnen laten bestellen bij AH's Albert.nl US07 - Als kok wil ik dat de applicatie een willekeurig recept of weekmenu kan genereren, rekening houdend met de voorkeuren van mijn club/gezin US08 - Daarbij mogen gekochte recepten van de laatste 2 weken niet herhaald worden.??? US09 - Als kok wil ik mijn vrienden van Hyves, Facebook en mogelijk andere social networks kunnen importeren als profiel US10 - Als eter wil ik mijn waardering voor een recept kunnen opvoeren US11 - Als architect wil ik dat de applicatie op termijn met meerdere bestelservices moeten kunnen werken User Stories Dennis Doomen

51. US1 Als kok wil ik recepten kunnen bijhouden met titel, beschrijving, instructies, bereidingstijd, ingredienten en moeilijkheidsgraad.

52. US1 Domain Model

53. Initial Reference Architecture Dennis Doomen Views (XAML + C#) Kitchen Service Domain Model Database

54. US1-A Als kok wil ik recepten kunt zoeken op titel, ingredienten, moeilijkheid en bereidingstijd

55. US2 Als kok wil ik kunnen zien wat de kosten van een recept bij benadering zijn (op basis van de productprijzen)

56. US2 (onderdeel van US2 – de product beheer scherm. In dit scherm worden product-unit-prijs gegevens vastgelegd en beheerd)

57. US2 Domain Model

58. US3 Als kok wil ik per eter een profiel kunnen bijhouden met naam, email, telefoonummer en adresgegevens.

59. US3 Domain Model

60. US4 Als kok wil ik per eter kunnen aangeven of de persoon allergisch is, het product niet lust, of het product liever niet eet

61. US4 (onderdeel van US4 – toevoegen/wijzigen van de eter voorkeur gegevens)

62. US4 Domain Model

63. US5 Als kok wil ik een boodschappenlijstje kunnen genereren o.b.v. een of meerdere recepten.

64. US6 Als kok wil ik de boodschappen kunnen laten bestellen bij AH's Albert.nl

65. US7 Als kok wil ik dat de applicatie een willekeurig recept of weekmenu kan genereren, rekening houdend met de voorkeuren van mijn club/gezin

66. US9 Als kok wil ik mijn vrienden van Hyves, Facebook en mogelijk andere social networks kunnen importeren als profiel

67. US9 (onderdeel van US9 – profiel import scherm, per social network)

68. US10 Als eter wil ik mijn waardering voor een recept kunnen opvoeren

69. US10 (onderdeel van US10 – als kok wil ik de mening van de eters over een recept kunnen bekijken)

70. The Kitchen Reference Architecture Dennis Doomen Application Shell Silverlight 4 Views (XAML + C#) DI MVVM Support View Models Commands Kitchen Context Application Services Unity for SL DTOs WCF RIA Services Unity Kitchen Service Domain Model Domain Events Domain Services Translation DI NHibernate(+ Fluent & LINQ) Service Agents Unit of Work Repositories AutoMapper Database AH, Hyves, Facebook