Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Cultivating Your Design Heuristics

128 views

Published on

This keynote was presented by Rebecca Wirfs-Brock at Explore DDD 2017.
The ouroboros (οὐροβόρος in the original Greek) is an image or archetype of a serpent shaped into a circle, clinging to or devouring its own tail in an endless cycle of self-destruction, self-creation, and self-renewal. Becoming a good software designer sometimes feels like that.

Over time, we build up our personal toolkit of design heuristics. To grow as designers, we need to do more than simply design and implement working software. We need to examine and reflect on our work, put our own spin on the advice of experts, and continue to learn better ways of designing.

Published in: Software
  • Be the first to comment

  • Be the first to like this

Cultivating Your Design Heuristics

  1. 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. 2. Heuristics  Heuristics aid in design  Guide use of other heuristics  Even determine our attitude and behavior
  3. 3. Examples
  4. 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. 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. 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. 7. Pattern Languages are never complete… © Can Stock Photo / TopVectors
  8. 8. Some Age Well! © Can Stock Photo / Noofoo
  9. 9. Heuristics May Conflict… and still be useful © Can Stock Photo / DaneeShe
  10. 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. 11. Table Module Heuristic p Solvable problems my problem Domain Model Heuristic Transaction Script
  12. 12. Table Module Heuristic p Solvable problems my problem Rich Domain Model Heuristic Transaction Script
  13. 13. Heuristics Need to be Challenged © Can Stock Photo / 4774344sean
  14. 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. 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. 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. 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. 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. 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. 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. 21. Nothing ever goes exactly by the book
  22. 22. Nothing ever goes exactly by the book
  23. 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. 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. 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. 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. 27. Responsibility-Driven Design (RDD) 1990 2002
  28. 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. 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. 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. 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. 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. 33. Sorting out heuristics…
  34. 34. © Can Stock Photo / andrewgenn
  35. 35. Let’s Just Get On With It © Can Stock Photo / Zinkevych
  36. 36. Sorting things out…
  37. 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. 38. Heuristics Need Champions
  39. 39. Books, blogs, case studies, critiques Reference apps Journaling, design logs..
  40. 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. 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. 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. 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. 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. 45. Cultivating Your Heuristics Requires Care and Attention
  46. 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. 47. Thank you! rebecca@wirfs-brock.com twitter: @rebeccawb

×