cultivating your design heuristics
TRANSCRIPT
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
The Nature of Heuristics
Heuristics aid in design
Guide use of other heuristics
Even determine our attitude and behavior
Examples
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)
ContextIn which situations
can I use this pattern?
ProblemWhat does it try to solve?
What questions does it answer?
SolutionWhat can I
do that usually works?
patterns are nicely
“packaged” heuristics
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
Pattern Languages are never complete…
© Can Stock Photo / TopVectors
Some Age Well!
© Can Stock Photo / Noofoo
Heuristics May Conflict…
and still be useful© Can Stock Photo / DaneeShe
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
Table ModuleHeuristic
p
Solvable problems
my problem
Domain Model Heuristic
Transaction Script
Table ModuleHeuristic
p
Solvable problems
my problem
RichDomain Model
Heuristic
Transaction Script
Heuristics Need to be Challenged
© Can Stock Photo / 4774344sean
Unscientific Chart: Maintenance Effort*
Database Script
Complexity of Domain Logic
Effort toEnhance
Transaction Script
Domain Model
Table Module
*Inspired by the unquantified chart in Fowler’s Patterns of Enterprise Architecture
Unscientific Chart: Code Reuse Potential*
Database Script
Transaction Script
Complexity of Domain Logic
PotentialCodeReuse
Domain Model
Table Module
*Inspired by the unquantified chart in Fowler’s Patterns of Enterprise Architecture
“Best Fit” ProfilesStyle Design Skills Driving Forces Project
DurationSystemComplexity
System Longevity
Transaction Script
Programming Dev speed Short Low Short
Domain Model- Rich
OO Design Business concepts in code
Medium Medium toHigh
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 toLong
Rules Engine
Specialized Complexity/ changeability
Long High Long
…
“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
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!
“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
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/
Nothing ever goes
exactly by the book
Nothing ever goes
exactly by the book
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
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
HeuristicsMy Design Recommendations✗
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”
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”
Responsibility-Driven Design (RDD)
1990
2002
RDD Concept: Role StereotypesTypical 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.
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)
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
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
Archive Delete
Delete
Modify
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/
Sorting out heuristics…
© Can Stock Photo / andrewgenn
Let’s Just Get On With It
© Can Stock Photo / Zinkevych
Sorting things out…
Beware of Dogma
DogmaticSynonyms: bullheaded, dictative, doctrinaire, fanatical, intolerant
Antonyms: amenable, flexible, manageable
PragmaticSynonyms: common, commonsense, practical, realistic, sensible
Antonyms: idealistic, unrealistic
Heuristics Need Champions
Books, blogs, case studies, critiques
Reference apps
Journaling, design logs..
“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
Advocacy: JournalingDescribe 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
ConstructiveReasonedClearTestableSignificant
Advocacy: JournalingDocument 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
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-decisionsUseful link to github project on decision records: https://github.com/joelparkerhenderson
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 sotabased on what you
learn.
Heuristic: Make small changes to your state-of-the-art (sota)
Cultivating Your
Heuristics Requires Care and Attention
Credits & Acknowledgements
Erik Simmons who encouraged me to read Discussion of TheMethod.
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.
