Dennis Doomenft. Jonne Kats & Peter Hesseling<br />Software Development Practices in Practice<br />
09:00 – 10:15Iteration 110:30 – 12:00	Iteration 212:00 – 13:00 	Lunch13:00 – 14:15	Iteration 314:30 – 15:45	Iteration 416:...
Orthogonal<br />Reversibility<br />Feedback<br />Iterative Development<br />Minimal Duplication<br />Aspects of software q...
Use Evolutionary Design & Reference Architecture<br />Treat your code as a book<br />Always check-in with better quality (...
Don't forget YAGNI <br />Don't make assumptions on legacy code<br />Use TDD or BDD<br />Consider using DDD if applicable<b...
The Kitchen<br />
Acceptance Testing Driven Development<br />Jonne Kats<br />
Breaks a complex domain into small chunks<br />Uses highly expressive models (typically UML sketches)<br />Intimately invo...
Ubiquitous Language<br />One common unambiguous language <br />Includes concepts and verbs<br />Ensures collaborate unders...
Entity<br />Has identity in domain<br />Identity never changes<br />Enforces business rules on its properties<br />Is not ...
Value Object<br />No identity, just lightweight data<br />Immutable<br />Behaves like a primitive type<br />Often reusable...
Aggregate<br />Closely related entities and value objects<br />Has global identity<br />Only accessed through its Aggregat...
Domain Services<br />Stateless<br />Often the entry point into the model<br />Enforce rules on multiple aggregates<br />Im...
Strategic Design<br />Bounded Contexts<br />Context Maps<br />Shared Kernel<br />Customer/supplier development teams<br />...
Unit Tests<br />Fast in-memory tests<br />Independent of any resources<br />Integration Tests<br />Access databases, files...
Small and focused<br />Intention revealing<br />Repeatable<br />Have no side-effects<br />Independent<br />Have a clear na...
It is important not to show what is not important<br />Use Object Mother or Test Data Builder<br />Signal the importance o...
Isolate The Ugly Stuff<br />Use Dependency Injection<br />Prefer state-based tests<br />Test one condition<br />Guidelines...
Is a design process<br />Great for quality tests<br />Tests are your first users<br />Can be your documentation<br />If TD...
Design Effects<br />More client control<br />More interfaces/factories<br />More focused<br />Less coupling<br />Problems<...
Stubs are stand-ins with fixed values<br />Mocks can be used for expectations<br />Frameworks: Rhino Mocks, NMock, MOQ, Ty...
Karl Seguin wrote:<br />Refusing<br />Getting too excited<br />Testing everything!<br />Integration testing<br />Discover ...
Safe Delete<br />Encapsulate Field<br />Use Base Type where Possible<br />Replace Constructor with Factory Method<br />Con...
Performance Testing<br />Peter Hesseling<br />
Flows naturally from user storiesAs a...I want...so that into Given...when...then<br />More behavior oriented<br />‘TDD Do...
MSpec 0.3<br />Behavior Driven Development<br />
Subspec<br />Behavior Driven Development<br />
The Kitchen Reference Architecture<br />Dennis Doomen<br />Application Shell<br />Silverlight 4<br />Views (XAML + C#)<br ...
The Principle of Least Surprise<br />Single Responsiblity Principle<br />Open Closed Principle<br />Liskov Substitution Pr...
Patterns<br />
Communicate design<br />Solve common challenges<br />Promote object-oriented design<br />Promote loose coupling and reuse<...
Technical Patternssingleton, factory, adapter, chain of responsibility, strategy, state, bridge, proxy, command, interpret...
Domain Patternsdomain model, transaction script, business actions, entity factory, repository, entity, value object, aggre...
Gregg Irwin said:<br />You use it without being aware<br />You hear about it, read up on it, and tinker a bit<br />You lea...
Only if the data and actions are available in all states!<br />State Pattern<br />
Domain Event Pattern<br />
Query-by-Example<br />Query Object<br />Specification<br />LINQ<br />Query Patterns<br />
Used in WCSF<br />Many interaction tests<br />Requires a lot of mocking<br />Strong view control<br />Model View Presenter...
Few interaction tests<br />Many state-based tests<br />Requires less mocking<br />No view control<br />Presentation Model<...
Microsoft variant of PM<br />Easy data binding<br />Bi-directional synchronization<br />Model View View-Model<br />
Responsibilities<br />Hides access to the DB<br />Behaves like a collection (implements ICollection<T>)<br />Could support...
Recommendations<br />Use an ORM such as NHibernate, Entity Framework or LLGenPro<br />One repository per DDD aggregate roo...
Responsibilities<br />Encapsulate peculiars of external systems<br />Reduces impact of changes<br />Facilitate single sign...
Recommendations<br />Use interfaces to enable mocking/stubbing<br />Use service agents for reporting servers and/of file I...
Clean Code<br />
Smells<br />Too many, output or flag  arguments<br />Inline Comments not related to a complex algorithm<br />Dead Code<br ...
Guidelines<br />Functions Names Should Say What  They Do and Should Do One Thing and be short<br />One Switch To Rule Them...
Case Study<br />The Kitchen<br />
US01 - Als kok wil ik recepten kunnen bijhouden met titel, beschrijving, instructies, bereidingstijd, ingredienten en moei...
US06 - Als kok wil ik de boodschappen kunnen laten bestellen bij AH's Albert.nl<br />US07 - Als kok wil ik dat de applicat...
US1<br />Als kok wil ik recepten kunnen bijhouden met titel, beschrijving, instructies, bereidingstijd, ingredienten en mo...
US1 Domain Model<br />
Initial Reference Architecture<br />Dennis Doomen<br />Views (XAML + C#)<br />Kitchen Service<br />Domain Model<br />Datab...
US1-A<br />Als kok wil ik recepten kunt zoeken op titel, ingredienten, moeilijkheid en bereidingstijd<br />
US2<br />Als kok wil ik kunnen zien wat de kosten van een recept bij benadering zijn (op basis van de productprijzen)<br />
US2<br />(onderdeel van US2 – de product beheer scherm. In dit scherm worden product-unit-prijs gegevens vastgelegd en beh...
US2 Domain Model<br />
US3<br />Als kok wil ik per eter een profiel kunnen bijhouden met naam, email, telefoonummer en adresgegevens.<br />
US3 Domain Model<br />
US4<br />Als kok wil ik per eter kunnen aangeven of de persoon allergisch is, het product niet lust, of het product liever...
US4<br />(onderdeel van US4 – toevoegen/wijzigen van de eter voorkeur gegevens)<br />
US4 Domain Model<br />
US5<br />Als kok wil ik een boodschappenlijstje kunnen genereren o.b.v. een of meerdere  recepten.<br />
US6<br />Als kok wil ik de boodschappen kunnen laten bestellen bij AH's Albert.nl<br />
US7<br />Als kok wil ik dat de applicatie een willekeurig recept of weekmenu kan genereren, rekening houdend met de voorke...
US9<br />Als kok wil ik mijn vrienden van Hyves, Facebook en mogelijk andere social networks kunnen importeren als profiel...
US9<br />(onderdeel van US9 – profiel import scherm, per social network)<br />
US10<br />Als eter wil ik mijn waardering voor een recept kunnen opvoeren<br />
US10<br />(onderdeel van US10 – als kok wil ik de mening van de eters over een recept kunnen bekijken)<br />
The Kitchen Reference Architecture<br />Dennis Doomen<br />Application Shell<br />Silverlight 4<br />Views (XAML + C#)<br ...
Upcoming SlideShare
Loading in …5
×

Software Development Practices in Practice

2,988 views
2,870 views

Published on

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

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

No Downloads
Views
Total views
2,988
On SlideShare
0
From Embeds
0
Number of Embeds
38
Actions
Shares
0
Downloads
0
Comments
0
Likes
9
Embeds 0
No embeds

No notes for slide
  • Orthogonality.  It’s a fancy word that just means being able to do or change or exercise one thing at a time.  It also means being able to understand or learn about one thing at a time in a system. Reversibility.  Technical or requirement decisions don’t have to be locked in stone. Feedback.  I think the best way to be successful building software is to assume that everything you do is wrong.  We need rapid feedback cycles to find and correct our inevitable mistakes. Iteration.  Your first idea is never your best idea.  Your business partners will need to refine their vision.  You need to be able to respond to both negative and positive feedback. Minimal Duplication.  Less duplication means easier change, less chance of making silly errors, and quicker iteration to get to the best product
  • Refactor aggressively in areas that change often, but never refactor just &apos;because it doesn&apos;t look nice&apos;
  • Refactor aggressively in areas that change often, but never refactor just &apos;because it doesn&apos;t look nice&apos;
  • Flows naturally from user stories in the form of As A, I Want, So That into multple BDD scenarios in the form of Given, When, THenMore behavior oriented, thus better for interaction testsTDD Done RightLijktmakkelijkertezijnommeetebeginnenomdat het woord &apos;test&apos; nietmeervoorkomtGeeft de intentiebeteraan door de verschillende &apos;should&apos; conditiiesLastigom met MSTestteimplementerenMeerdere frameworks ommeetewerken, en nognieteentje die boven de rest uitsteekt
  • Flows naturally from user stories in the form of As A, I Want, So That into multple BDD scenarios in the form of Given, When, THenMore behavior oriented, thus better for interaction testsTDD Done RightLijktmakkelijkertezijnommeetebeginnenomdat het woord &apos;test&apos; nietmeervoorkomtGeeft de intentiebeteraan door de verschillende &apos;should&apos; conditiiesLastigom met MSTestteimplementerenMeerdere frameworks ommeetewerken, en nognieteentje die boven de rest uitsteekt
  • Flows naturally from user stories in the form of As A, I Want, So That into multple BDD scenarios in the form of Given, When, THenMore behavior oriented, thus better for interaction testsTDD Done RightLijktmakkelijkertezijnommeetebeginnenomdat het woord &apos;test&apos; nietmeervoorkomtGeeft de intentiebeteraan door de verschillende &apos;should&apos; conditiiesLastigom met MSTestteimplementerenMeerdere frameworks ommeetewerken, en nognieteentje die boven de rest uitsteekt
  • Repositories regelen toegang tot de database (vaak via een ORM) en gedragen zich als een object collectie (interface is gebaseerd op die van ICollection).Repositories worden altijd via een interface opgehaald (b.v. via een factory)De scope van de unit-of-work wordt door de BA bepaald en niet door de repositories Idealiter ondersteunt de repository eigenschappen van TransparentPersistency, b.v. lazylaoding van relaties tussen entiteiten en het automatisch flushen van alle wijzigingen binnen een unit-of-work. Verzorgt optimalisaties om de database te ontlasten, zoals b.v. first en second-levelcaches, query caching, e.t.c Zorgt dat technische database-specifieke fouten afgeschermd worden en vervangen door functionele fouten
  • De meeste ORMs ondersteunen alle gewenste functionaliteit. Ik gebruik Nhibernate en Nhibernate.LINQ Definieer 1 repository voor elke aggregatie root Laat toegang tot repositories altijd verlopen via een interface zodat de repository altijd gemocked kan worden Implementeer Iqueryable (b.v. Nhibernate.LINQ) zodat de aanroepende code LINQ queries kan uitvoeren zonder dat dit performanceproblemen veroorzaken. Gebruik Query Object pattern of Specification om een enorme lijst van FindXXX methodes met verschillende argumenten te voorkomen.
  • Een service agent zit tussen het domein model of BA en een extern systeem (of subsysteem) en schermt alle technische afhankelijkheden af. Doel? De impact van externe wijzigingen minimaliseren. Ook kan een SA de verschillen tussen interne en externe accounts transparant maken (mapping tussen accounts) zodat single sing-on mogelijk is. Biedt optimalisatie aan zoals caching, retries, auditing, logging, e.t.c. Verzorgt de monitoring en tracing van de interactie met de externe systemen, en kan bijvoorbeeld actief signaleren als bepaalde operaties opvallen lang duren.
  • Service Agents altijd via interfaces aanroepen om unittesten te kunnen schrijven zonder het externe systeem. Ook toegang tot files of networklocaties en reporting engines zijn ‘extern’ en moeten via service agents verlopen. Aangezien een service agents van nature long-running zijn, moeten die in principe altijd via een WF verlopen. Let op, in de praktijk gebeurt dit niet zo vaak.
  • Inconsistency (solve similar problems with similar solutions)
  • Inconsistency (solve similar problems with similar solutions)
  • Software Development Practices in Practice

    1. 1. Dennis Doomenft. Jonne Kats & Peter Hesseling<br />Software Development Practices in Practice<br />
    2. 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<br />Agenda<br />Product Backlog<br />Aspects of Software Quality<br />The Demo Case<br />Acceptance Testing<br />Domain Driven Design <br />Automatic Testing<br />Test Driven Development<br />Mocking<br />RefactoringPerformance Testing<br />Behavior Driven Development<br />Design Principles & Patterns<br />Clean Code<br />CQRS<br />
    3. 3. Orthogonal<br />Reversibility<br />Feedback<br />Iterative Development<br />Minimal Duplication<br />Aspects of software quality<br />
    4. 4. Use Evolutionary Design & Reference Architecture<br />Treat your code as a book<br />Always check-in with better quality (!= software rot)<br />Adhere to Clean Code<br />Use Coding Guidelines<br />Prevent duplication<br />The Golden Rules<br />
    5. 5. Don't forget YAGNI <br />Don't make assumptions on legacy code<br />Use TDD or BDD<br />Consider using DDD if applicable<br />Refactor aggressively <br />Design towards patterns<br />More Golden Rules<br />
    6. 6. The Kitchen<br />
    7. 7. Acceptance Testing Driven Development<br />Jonne Kats<br />
    8. 8. Breaks a complex domain into small chunks<br />Uses highly expressive models (typically UML sketches)<br />Intimately involves business <br />Understandable by everyone<br />Promotes a loosely coupled design<br />Provides guidelines for large organizations<br />Domain Driven Design<br />
    9. 9. Ubiquitous Language<br />One common unambiguous language <br />Includes concepts and verbs<br />Ensures collaborate understanding of the domain<br />Originates from business<br />Maintain a glossary (incl. translations)<br />Apply to everything; code, tests, UI<br />When refactoring, refactor everything<br />Domain Driven Design<br />
    10. 10. Entity<br />Has identity in domain<br />Identity never changes<br />Enforces business rules on its properties<br />Is not directly accessible<br />Often has a functional identifier<br />Domain Driven Design<br />
    11. 11. Value Object<br />No identity, just lightweight data<br />Immutable<br />Behaves like a primitive type<br />Often reusable<br />Examples: TimeFrame, ISBN, PostalCode, Email, Address<br />Domain Driven Design<br />
    12. 12. Aggregate<br />Closely related entities and value objects<br />Has global identity<br />Only accessed through its Aggregate Root entity<br />Ensures integrity of all entities<br />Typically loaded and saved as one unit<br />Loaded using a repository and (often) created using a factory<br />Deleting the root, deletes everything in the aggregate<br />Domain Driven Design<br />
    13. 13. Domain Services<br />Stateless<br />Often the entry point into the model<br />Enforce rules on multiple aggregates<br />Implemented as methods or Commands<br />Domain Driven Design<br />
    14. 14. Strategic Design<br />Bounded Contexts<br />Context Maps<br />Shared Kernel<br />Customer/supplier development teams<br />Conformist<br />Anti-corruption layer<br />Separate Ways<br />Domain Driven Design<br />
    15. 15. Unit Tests<br />Fast in-memory tests<br />Independent of any resources<br />Integration Tests<br />Access databases, files, services, I/O <br />End-2-End Tests <br />Full tests including all related systems<br />Automated Testing<br />
    16. 16. Small and focused<br />Intention revealing<br />Repeatable<br />Have no side-effects<br />Independent<br />Have a clear name <br />Tests should be...<br />
    17. 17. It is important not to show what is not important<br />Use Object Mother or Test Data Builder<br />Signal the importance of variables using 'a', 'the', 'some‘<br />Start small<br />Test what you know now (and assemble the rest)<br />Guidelines for testing<br />
    18. 18. Isolate The Ugly Stuff<br />Use Dependency Injection<br />Prefer state-based tests<br />Test one condition<br />Guidelines for testing<br />
    19. 19. Is a design process<br />Great for quality tests<br />Tests are your first users<br />Can be your documentation<br />If TDD hurts => you're doing it wrong<br />Red-Green-Refactor<br />Better for state-based tests<br />Test Driven Development<br />28 May 2009<br />Dennis Doomen<br />
    20. 20. Design Effects<br />More client control<br />More interfaces/factories<br />More focused<br />Less coupling<br />Problems<br />UI<br />Persistent Data<br />False sense of security<br />Losing the overview<br />More code to maintain<br />Test Driven Development<br />
    21. 21. Stubs are stand-ins with fixed values<br />Mocks can be used for expectations<br />Frameworks: Rhino Mocks, NMock, MOQ, TypeMock (commercial)<br />Guidelines<br />Don't mock chatty interfaces<br />Don't have more than 2-3 mocks per test<br />Only mock your nearest neigbors<br />Mocking<br />28 May 2009<br />Dennis Doomen<br />
    22. 22. Karl Seguin wrote:<br />Refusing<br />Getting too excited<br />Testing everything!<br />Integration testing<br />Discover mocking<br />Mocking everything<br />Becoming effective<br />Phases of automated testing<br />28 May 2009<br />Dennis Doomen<br />
    23. 23. Safe Delete<br />Encapsulate Field<br />Use Base Type where Possible<br />Replace Constructor with Factory Method<br />Convert Extension Method to Plain Static (vv)<br />Convert Method to Property (vv)<br />Convert Property to Auto-Property <br />Extract Class from Parameters<br />Rename Member / Type<br />Rename / Move Namespace<br />Extract Interface / Method / Superclass<br />Pull Up & Down<br />Introduce Field, Variable or Parameter<br />Move To File (in Folder)<br />Change Signature<br />Refactoring<br />
    24. 24. Performance Testing<br />Peter Hesseling<br />
    25. 25. Flows naturally from user storiesAs a...I want...so that into Given...when...then<br />More behavior oriented<br />‘TDD Done Right’<br />Great for exploring the Ubiquitous Language using exploratory specs<br />Seems easier to start with<br />More intention revealing<br />Difficult to implement with MSTest<br />No single framework (yet)<br />Behavior Driven Development<br />
    26. 26. MSpec 0.3<br />Behavior Driven Development<br />
    27. 27. Subspec<br />Behavior Driven Development<br />
    28. 28. The Kitchen Reference Architecture<br />Dennis Doomen<br />Application Shell<br />Silverlight 4<br />Views (XAML + C#)<br />DI<br />MVVM Support<br />View Models<br />Commands<br />Controller<br />Kitchen Context<br />Application Services<br />Unity for SL<br />DTOs<br />WCF RIA Services<br />Enterprise Library<br />Kitchen Service<br />Domain Model<br />Domain Events<br />Domain Services<br />Translation<br />Policy Injection<br />Validation<br />Logging<br />DI<br />NHibernate(+ Fluent & LINQ)<br />Service Agents<br />Unit of Work<br />Repositories<br />AutoMapper<br />Database<br />Backoffice Systems<br />
    29. 29. The Principle of Least Surprise<br />Single Responsiblity Principle<br />Open Closed Principle<br />Liskov Substitution Principle<br />Interface Seggregation Principle<br />Dependency Inversion Principle<br />Law of Demeter (a.k.a. Writing Shy Code)<br />Command Query Separation<br />Design Principles<br />
    30. 30. Patterns<br />
    31. 31. Communicate design<br />Solve common challenges<br />Promote object-oriented design<br />Promote loose coupling and reuse<br />Go hand in hand with S.O.L.I.D.<br />Purpose of Patterns<br />
    32. 32. Technical Patternssingleton, factory, adapter, chain of responsibility, strategy, state, bridge, proxy, command, interpreter, mediator, memento, observer, template, composite<br />Architectural PatternsCQRS, layer supertype, SOA, MVC, MVP, PM, Pipes & Filters, <br />Patterns Examples<br />
    33. 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<br />Patterns Examples<br />
    34. 34. Gregg Irwin said:<br />You use it without being aware<br />You hear about it, read up on it, and tinker a bit<br />You learn more and start using it explicitly, if naïvely<br />You get the fire and evangelize<br />Something "clicks"<br />You learn more and apply it "less naïvely" and more implicitly<br />Time passes and you see flaws<br />You question the concept (often because you misapplied it)<br />You either forget about it or add knowledge and experience<br />You use it without being aware that you're using it<br />Phases of Pattern Adoption<br />
    35. 35. Only if the data and actions are available in all states!<br />State Pattern<br />
    36. 36. Domain Event Pattern<br />
    37. 37. Query-by-Example<br />Query Object<br />Specification<br />LINQ<br />Query Patterns<br />
    38. 38. Used in WCSF<br />Many interaction tests<br />Requires a lot of mocking<br />Strong view control<br />Model View Presenter<br />
    39. 39. Few interaction tests<br />Many state-based tests<br />Requires less mocking<br />No view control<br />Presentation Model<br />
    40. 40. Microsoft variant of PM<br />Easy data binding<br />Bi-directional synchronization<br />Model View View-Model<br />
    41. 41. Responsibilities<br />Hides access to the DB<br />Behaves like a collection (implements ICollection<T>)<br />Could support Transparent Persistency<br />Lazy loading<br />Automatic flushing<br />Provides optimizations such as caching<br />Provides exception shielding<br />Repository Pattern<br />
    42. 42. Recommendations<br />Use an ORM such as NHibernate, Entity Framework or LLGenPro<br />One repository per DDD aggregate root<br />Use interfaces to allow faking/stubing<br />Implement IQueryable (LINQ)<br />Use Query Object or Specification patterns<br />Repository Pattern<br />
    43. 43. Responsibilities<br />Encapsulate peculiars of external systems<br />Reduces impact of changes<br />Facilitate single sign-on <br />Caching<br />Resistant against temporary network problems<br />Monitoring and tracing<br />Service Agents<br />
    44. 44. Recommendations<br />Use interfaces to enable mocking/stubbing<br />Use service agents for reporting servers and/of file I/O<br />Use a workflow<br />Service Agents<br />
    45. 45. Clean Code<br />
    46. 46. Smells<br />Too many, output or flag arguments<br />Inline Comments not related to a complex algorithm<br />Dead Code<br />Inconsistency (solve similar problems with similar solutions)<br />Artificial Coupling<br />Obscured Intent<br />Misplaced Responsibility<br />Clean Code<br />
    47. 47. Guidelines<br />Functions Names Should Say What They Do and Should Do One Thing and be short<br />One Switch To Rule Them All (!)<br />Be Precise<br />Don' Mix Levels of Abstractions<br />Always treat warnings as errors<br />Clean Code<br />
    48. 48. Case Study<br />The Kitchen<br />
    49. 49. US01 - Als kok wil ik recepten kunnen bijhouden met titel, beschrijving, instructies, bereidingstijd, ingredienten en moeilijkheidsgraad.<br />US02 - Als kok wil ik kunnen zien wat de kosten van een recept bij benadering zijn (op basis van de productprijzen)<br />US03 - Als kok wil ik per eter een profiel kunnen bijhouden met naam, adres, telefoonummer en adresgegevens.<br />US 04 - Als kok wil ik per eter kunnen aangeven of een eter allergisch is, dat product niet lust, of liever niet eet<br />US05 - Als kok wil ik een boodschappenlijstje kunnen genereren o.b.v. een of meerdere recepten.<br />User Stories<br />Dennis Doomen<br />
    50. 50. US06 - Als kok wil ik de boodschappen kunnen laten bestellen bij AH's Albert.nl<br />US07 - Als kok wil ik dat de applicatie een willekeurig recept of weekmenu kan genereren, rekening houdend met de voorkeuren van mijn club/gezin<br />US08 - Daarbij mogen gekochte recepten van de laatste 2 weken niet herhaald worden.???<br />US09 - Als kok wil ik mijn vrienden van Hyves, Facebook en mogelijk andere social networks kunnen importeren als profiel<br />US10 - Als eter wil ik mijn waardering voor een recept kunnen opvoeren<br />US11 - Als architect wil ik dat de applicatie op termijn met meerdere bestelservices moeten kunnen werken<br />User Stories<br />Dennis Doomen<br />
    51. 51. US1<br />Als kok wil ik recepten kunnen bijhouden met titel, beschrijving, instructies, bereidingstijd, ingredienten en moeilijkheidsgraad.<br />
    52. 52. US1 Domain Model<br />
    53. 53. Initial Reference Architecture<br />Dennis Doomen<br />Views (XAML + C#)<br />Kitchen Service<br />Domain Model<br />Database<br />
    54. 54. US1-A<br />Als kok wil ik recepten kunt zoeken op titel, ingredienten, moeilijkheid en bereidingstijd<br />
    55. 55. US2<br />Als kok wil ik kunnen zien wat de kosten van een recept bij benadering zijn (op basis van de productprijzen)<br />
    56. 56. US2<br />(onderdeel van US2 – de product beheer scherm. In dit scherm worden product-unit-prijs gegevens vastgelegd en beheerd)<br />
    57. 57. US2 Domain Model<br />
    58. 58. US3<br />Als kok wil ik per eter een profiel kunnen bijhouden met naam, email, telefoonummer en adresgegevens.<br />
    59. 59. US3 Domain Model<br />
    60. 60. US4<br />Als kok wil ik per eter kunnen aangeven of de persoon allergisch is, het product niet lust, of het product liever niet eet<br />
    61. 61. US4<br />(onderdeel van US4 – toevoegen/wijzigen van de eter voorkeur gegevens)<br />
    62. 62. US4 Domain Model<br />
    63. 63. US5<br />Als kok wil ik een boodschappenlijstje kunnen genereren o.b.v. een of meerdere recepten.<br />
    64. 64. US6<br />Als kok wil ik de boodschappen kunnen laten bestellen bij AH's Albert.nl<br />
    65. 65. US7<br />Als kok wil ik dat de applicatie een willekeurig recept of weekmenu kan genereren, rekening houdend met de voorkeuren van mijn club/gezin<br />
    66. 66. US9<br />Als kok wil ik mijn vrienden van Hyves, Facebook en mogelijk andere social networks kunnen importeren als profiel<br />
    67. 67. US9<br />(onderdeel van US9 – profiel import scherm, per social network)<br />
    68. 68. US10<br />Als eter wil ik mijn waardering voor een recept kunnen opvoeren<br />
    69. 69. US10<br />(onderdeel van US10 – als kok wil ik de mening van de eters over een recept kunnen bekijken)<br />
    70. 70. The Kitchen Reference Architecture<br />Dennis Doomen<br />Application Shell<br />Silverlight 4<br />Views (XAML + C#)<br />DI<br />MVVM Support<br />View Models<br />Commands<br />Kitchen Context<br />Application Services<br />Unity for SL<br />DTOs<br />WCF RIA Services<br />Unity<br />Kitchen Service<br />Domain Model<br />Domain Events<br />Domain Services<br />Translation<br />DI<br />NHibernate(+ Fluent & LINQ)<br />Service Agents<br />Unit of Work<br />Repositories<br />AutoMapper<br />Database<br />AH, Hyves, Facebook<br />

    ×