Agile methodology in cloud computing
Your SlideShare is downloading.
×
Check these out next
Recommended
More Related Content
Slideshows for you (20)
Similar to Cultivating Your Design Heuristics (20)
Recently uploaded (20)
Cultivating Your Design Heuristics
- 1. Heuristic “anything that provides a plausible aid or direction in the solution of a problem but is in the final analysis unjustified, incapable of justification, and potentially fallible.” —Billy Vaughn Koen
- 2. Heuristics Heuristics aid in design Guide use of other heuristics Even determine our attitude and behavior
- 3. Examples
- 4. Pithy Phrases? A Few Useful Engineering Heuristics by Billy Koen Heuristic: Solve problems by successive approximations Heuristic: Always give an answer Heuristic: Always give yourself a chance to retreat Heuristic: Use feedback to stabilize the design Heuristic: Break complex problems into smaller, more manageable pieces Heuristic: Always make the minimum decision Heuristic: Design for a specific time frame (product lifetime) Heuristic: Make small changes to your state-of-the-art (sota)
- 5. Context In which situations can I use this pattern? Problem What does it try to solve? What questions does it answer? Solution What can I do that usually works? patterns are nicely “packaged” heuristics
- 6. Pattern Languages “In short, no pattern is an isolated entity. Each pattern can exist in the world only to the extent that is supported by other patterns: the larger patterns in which it is embedded, the patterns of the same size that surround it, and the smaller patterns which are embedded in it.” —Christopher Alexander © Can Stock Photo / sauletas
- 7. Pattern Languages are never complete… © Can Stock Photo / TopVectors
- 8. Some Age Well! © Can Stock Photo / Noofoo
- 9. Heuristics May Conflict… and still be useful © Can Stock Photo / DaneeShe
- 10. Heuristic: Use a Transaction Script when you have simple logic for a small database application Heuristic: Use a Domain Model when you have complex logic that you want to model in objects and can accommodate database mapping Heuristic: Use a Table Module when you have complex (existing) data and you need to write logic that applies to multiple rows in underlying database tables Heuristics: 3 Ways to Structure a Domain Layer Patterns of Enterprise Application Architecture
- 11. Table Module Heuristic p Solvable problems my problem Domain Model Heuristic Transaction Script
- 12. Table Module Heuristic p Solvable problems my problem Rich Domain Model Heuristic Transaction Script
- 13. Heuristics Need to be Challenged © Can Stock Photo / 4774344sean
- 14. Unscientific Chart: Maintenance Effort* Database Script Complexity of Domain Logic Effort to Enhance Transaction Script Domain Model Table Module *Inspired by the unquantified chart in Fowler’s Patterns of Enterprise Architecture
- 15. Unscientific Chart: Code Reuse Potential* Database Script Transaction Script Complexity of Domain Logic Potential Code Reuse Domain Model Table Module *Inspired by the unquantified chart in Fowler’s Patterns of Enterprise Architecture
- 16. “Best Fit” Profiles Style Design Skills Driving Forces Project Duration System Complexity System Longevity Transaction Script Programming Dev speed Short Low Short Domain Model- Rich OO Design Business concepts in code Medium Medium to High Medium to Long Domain Model- Simple Moderate OO +DB Simple representation of business concepts Medium Medium Medium Database script Specialized Performance, security Medium Low to Medium Long Table Module DB + Moderate prog/OO design Technology fit Medium Low to Medium Medium to Long Rules Engine Specialized Complexity/ changeability Long High Long …
- 17. “As a rule, the more demanding the application, the more leverage you get from using a powerful language. But plenty of projects are not demanding at all. Most programming probably consists of writing little glue programs, and for little glue programs you can use any language that you’re already familiar with and that has good libraries for whatever you need to do” — Paul Graham, Revenge of the Nerds
- 18. The “best” is debatable Paul Graham’s Heuristic: It doesn’t matter what programming language you use if you have a simple program. Use programming languages, tools, and frameworks and libraries you are familiar with. Rebecca: But Paul… Heuristic: Use a rich domain model when you have rich behavior in your application. Heuristic: Use transaction scripts for really simple stuff that isn’t going to change much. Heuristic: Learn something new. Don’t always do things the same way. That’s soul sucking!
- 19. “choose the heuristic to use from what you take to be the best option at the time you are required to choose.” —paraphrase of Billy Koen
- 20. We each have our own cherished heuristics As new ones become useful we add to our collection No longer useful ones fall out of fashion Sometimes, even useful ones fade away Our SOTA (State of the Art) https://xkcd.com/1823/
- 21. Nothing ever goes exactly by the book
- 22. Nothing ever goes exactly by the book
- 23. Choices for user input validation: How much to validate in the browser? Hand code validation logic or use declarative style? How much validation is performed by framework- specific classes: simple, syntactic edits, or more? Choices for constraint checking: Which objects are assigned constraint checking responsibilities? When are constraints enforced? Where to enforce cross-attribute and cross-object constraints? An Examination of some Pesky Details: Validation and Constraint Checking
- 24. Perform simple edits (syntactic) in browser code Don’t universally trust browser-validated edits. Reapply them if receiving requests from an untrusted source Consistently assign validation responsibilities to framework-specific validation classes Consistently use domain layer validation and constraint enforcement patterns Heuristics My Design Recommendations ✗
- 25. Rationale: Factoring out constraint checking behavior into a separate class enables constraints be enforced by a domain service, that can determine when to check constraints. Merit: Possible to dynamically configure constraints. Drawback: Harder to understand all the rules at once. Option 1: Make Constraints Explicit Create Separate Classes “xxxPolicy” or “xxxRule” is a common name for constraint objects Constraint: “An out of stock item can’t be added to an expedited order”
- 26. Rationale: Putting a constraint in the code that changes the state is most direct. Merit: Factoring constraint into an intentionally named helper method aids discussing with domain experts. Drawback: Clutters the domain object with a lot of checking, creates dependencies on other domain objects. No ability to modulate when constraints are enforced. Option 2: Give objects responsibilities for maintaining their state Check Constraints in Domain Object Constraint: “An out of stock item can’t be added to an expedited order”
- 27. Responsibility-Driven Design (RDD) 1990 2002
- 28. RDD Concept: Role Stereotypes Typical behaviors in an object-oriented design knowing, doing, deciding Information holder—knows and provides information. Structurer—maintains relationships between objects. Service provider—performs work on demand. Coordinator—reacts to events by delegating to others. Controller—makes decisions & directs actions. Interfacer—transforms information and requests between distinct parts of a software system.
- 29. RDD Heuristic: Blend stereotypes to make objects more responsible. Add behaviors to make objects “smarter” information holders that compute or derive information based on other information they maintain service providers that maintain information to be more efficient structurers that answer deeper questions or derive facts about what they are structuring interfacers that also transform Be constantly aware of Overlapping Heuristics Heuristic: Design objects to do one thing well. (Single Responsibility Principle from Bob Martin) Heuristic: Make the overall system simpler by having objects do something with what they know. (Responsibility-Driven Design Heuristic)
- 30. 2001 People, Places, Things, Aggregate Things, Events Heuristic: Separate out stuff that varies depending on the current relationship Heuristic: Locations can be hierarchical or even more complex Heuristic: Events can be point-in-time, interval, depend on other events …and event information is often messy and complex
- 31. Heuristic: By characterizing a domain entity’s attributes you can understand/find/identify needed system behaviors Descriptive Attributes reflect a domain object properties (not identity). Time-dependent attributes Most attributes can change values, but for some, maintaining a history of past values is important. Lifecycle state attributes Some entities go through a one-way lifecycle, from initial to final state. Operational state Some entities switch between different states. The state it is currently in determines how it behaves. Create Active Store Reconstitute Database Representation Database or File Representation ArchiveDelete Delete Modify
- 32. Heuristic*: Distinguish between “superficial” and “domain” validations and handle them differently “superficial”: what must be true, regardless of the state of the domain Heuristic: Validate these before issuing a command, ideally on the client side as well as the server side “superficial” but requires lookup of other information Heuristic: Validate in the service before invoking the command “domain”: validity of a command is dependent on the state of the model Heuristic: Validate in domain objects *http://danielwhittaker.me/2016/04/20/how-to-validate-commands-in-a-cqrs-application/
- 33. Sorting out heuristics…
- 34. © Can Stock Photo / andrewgenn
- 35. Let’s Just Get On With It © Can Stock Photo / Zinkevych
- 36. Sorting things out…
- 37. Beware of Dogma Dogmatic Synonyms: bullheaded, dictative, doctrinaire, fanatical, intolerant Antonyms: amenable, flexible, manageable Pragmatic Synonyms: common, commonsense, practical, realistic, sensible Antonyms: idealistic, unrealistic
- 38. Heuristics Need Champions
- 39. Books, blogs, case studies, critiques Reference apps Journaling, design logs..
- 40. “The Tactical Modeling patterns were never intended to be the one-and-only way to do DDD, but many consider them as such. They produce extraneous noise and detract attention away from the most important, and unique-to-DDD material.” —Vladik Khononov *http://vladikk.com/2016/04/05/tackling-complexity-ddd/ What if we removed the tactical patterns?* Advocacy: Blogging/Critique
- 41. Advocacy: Journaling Describe Your Design Principles Guidelines: You prefer a rich domain model Aggregate roots should not directly communicate with each other Communication protocols and why Conventions: Common service interfaces/capabilities Extension points configured by… When you can break the rules... 53 Constructive Reasoned Clear Testable Significant
- 42. Advocacy: Journaling Document Decisions Rationale—why you made it Other options considered An appreciation of your thought process Goal: Convey why your architecture, or a piece of it, is a good solution 54 Decisions worth justifying Spent lots of time on Critical to achieving a requirement Confusing at first Widespread impact Difficult to undo
- 43. One option* 1-2 pages of text describing a set of forces forces & a single decision in response Title Context - Forces at play Decision - Stated with active voice: "We will ..." Status - “proposed” or “accepted” later may be “deprecated” or “superseded” Consequences positive, negative, and neutral that affect the team and project in the future *Useful for recorded decisions that have a “lifecycle”. Thanks to Michael Nygard: http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions Useful link to github project on decision records: https://github.com/joelparkerhenderson
- 44. Used with permissions under the under the Creative Commons Attribution-Share Alike 3.0 Unportedicense. By MichaelMaggs Edit by Richard Bartz (Own work) [CC BY-SA 3.0 (http://creativecommons.org/licenses/by-sa/3.0)], via Wikimedia Commons Reshape your sota based on what you learn. Heuristic: Make small changes to your state-of-the-art (sota)
- 45. Cultivating Your Heuristics Requires Care and Attention
- 46. Credits & Acknowledgements Erik Simmons who encouraged me to read Discussion of The Method. Richard Gabriel, a thinker and doer, critic of my work, and inspiration too. Eric Evans always makes me think deeply about design matters. The Ouroboros image is from the Ouroboric Philosophy page, an inspiration https:ouroboricphilosophy.wordpress.com/tag/ouroboros/ Rebecca Wirfs-Brock photograph of the Blue Apron meal. Allen Wirfs-Brock photograph of Rebecca Wirfs-Brock at Haystack Rock.
- 47. Thank you! rebecca@wirfs-brock.com twitter: @rebeccawb
