├── .gitignore ├── 404.md ├── Gemfile ├── Gemfile.lock ├── LICENSE ├── README.md ├── _config.yml ├── _data └── navigation.yml ├── _design-heuristics ├── a-bounded-context-should-keep-its-internal-details-private.md ├── align-bounded-context-with-the-value-stream.md ├── align-with-domain-experts.md ├── align-with-evolutionary-stage.md ├── align-with-growth-strategy.md ├── align-with-historical-domain-boundaries.md ├── align-with-investment-strategy.md ├── align-with-key-revenue-streams.md ├── align-with-rate-of-change.md ├── align-with-source-of-change.md ├── align-with-transactional-boundaries.md ├── build-software-for-disruptive-generic-subdomains-yourself.md ├── design-bounded-context-around-eventstorming-policies.md ├── design-bounded-context-by-looking-at-the-humans-during-big-picture-eventstorming.md ├── design-bounded-contexts-by-looking-at-the-one-way-flow-of-orange-sticky-notes-during-a-big-picture-eventstorming.md ├── design-for-replayability.md ├── isolate-high-leverage-shared-capabilities.md ├── keep-your-domain-model-decoupled-from-frameworks.md ├── optimise-for-future-potential.md ├── organise-for-responsiveness-in-differentiator-capabilities.md ├── outsource-generic-subdomains.md ├── seperate-engagement-and-revenue.md └── use-orm-in-domain-model-when-rate-of-change-is-low.md ├── _guiding-heuristics ├── always-write-gherkin.md ├── eventstorming-add-minority-wisdom-to-decision.md ├── eventstorming-add-more-detail-with-invisible-conversation.md ├── eventstorming-ask-is-this-always-the-case-on-policy.md ├── eventstorming-do-big-picture-eventstorming-on-a-single-paper-roll.md ├── eventstorming-dont-be-shy-on-duplicating-stickies.md ├── eventstorming-dont-fill-in-the-gaps.md ├── eventstorming-emerging-pivotal-events-for-a-big-picture.md ├── eventstorming-explore-what-if-scenarios.md ├── eventstorming-introduce-new-colours-iteratively.md ├── eventstorming-let-every-pitch-for-hotspots-opportunities.md ├── eventstorming-let-the-domain-expert-talk-and-the-rest-write-down-domain-events.md ├── eventstorming-make-a-ceremony-of-throwing-stickies-away.md ├── eventstorming-one-facilitator-for-every-15-participants.md ├── eventstorming-only-move-or-remove-stickies-when-discussed-with-the-writer.md ├── eventstorming-play-by-the-colour-coding-pattern.md ├── eventstorming-remove-stickies-when-group-feels-sunk-cost.md ├── eventstorming-split-and-merge-above-7-people.md ├── eventstorming-split-and-merge-during-converging-discussions.md ├── eventstorming-start-enforcing-the-timeline-when-everyone-added-their-domain-events.md ├── eventstorming-switch-to-example-mapping-when-discussing-examples-of-a-rule.md ├── eventstorming-use-as-is-process-modelling-when-exploring-a-green-field-problem-space.md ├── eventstorming-use-consistent-language-between-visual-collaboration-tools.md ├── eventstorming-use-standing-tables.md ├── eventstorming-use-to-be-process-modelling-when-exploring-a-brown-field-problem-space.md ├── eventstorming-when-there-is-a-story-to-tell-start-with-eventstorming.md ├── everyone-can-write-gherkin.md ├── example-mapping-prepare-visualisations-upfront.md ├── example-mapping-split-business-rule-above-3-examples.md ├── example-mapping-split-business-rule-when-an-example-has-more-than-one-check.md ├── example-mapping-split-the-story-on-business-rules.md ├── example-mapping-use-a-maximum-of-20-minutes-for-a-story.md ├── example-mapping-visualise-examples.md ├── example-mapping-write-down-any-future-wishes-on-a-red-sticky.md ├── example-mapping-write-down-domain-concepts-on-a-white-sticky.md ├── example-mapping-write-examples-as-intentions-over-implementation.md ├── explore-language-change-language-to-change-how-people-think.md ├── let-someone-from-another-team-facilitate-your-teams-collaborative-modelling-session.md ├── remote-eventstorming-break-out-groups-between-pivotal-events.md ├── remote-eventstorming-do-breaks-after-10-20-min-of-work.md ├── remote-eventstorming-everyone-has-their-camera-on.md ├── remote-eventstorming-have-a-dedicated-facilitator.md ├── remote-eventstorming-let participants move in breaks.md ├── remote-eventstorming-run-for-a-maximum-of-two-hours-in-a-day.md ├── remote-eventstorming-switch-driver-every-5-minutes-during-enforcing-the-timeline.md ├── remote-eventstorming-use-a-mobprogramming-style-enforcing-the-timeline.md ├── start-a-workshop-with-a-checkin.md └── stories-starting-with-todos-are-smell.md ├── _includes └── documents-collection.html ├── _layouts └── heuristics.html ├── _pages ├── align-with-business-value.md ├── behaviour-driven-development.md ├── design-heuristics.md ├── eventstorming.md ├── example-mapping.md ├── guiding-heuristics.md ├── heuristics.md ├── remote-eventstorming.md ├── submit.md └── value-based-heuristics.md ├── _value-based-heuristics └── deep-democracy-everyone-is-right-no-one-has-the-monopoly-to-the-truth.md ├── assets └── images │ ├── blank-avatar.png │ ├── bounded-context.png │ ├── emerging-pivotal-events.png │ ├── eventstorming-colour-coding.jpg │ ├── kandinsky.jpg │ ├── remote-eventstorming-bp-break-out.png │ ├── value-stream-contexts.png │ ├── value-stream-events.png │ ├── value-stream.png │ └── vddd_logo_small.png ├── index.md └── netlify.toml /.gitignore: -------------------------------------------------------------------------------- 1 | 2 | \.sass-cache/ 3 | _site/ 4 | .bundle 5 | Gemfile.lock 6 | .DS_Store 7 | .jekyll-cache/ 8 | **/*.iml 9 | .idea/ 10 | -------------------------------------------------------------------------------- /404.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "404" 3 | excerpt: "Page Not Found" 4 | permalink: 404.html 5 | indexing: false 6 | sitemap: false 7 | --- 8 | 9 | Sorry, but the page could not be found. 10 | -------------------------------------------------------------------------------- /Gemfile: -------------------------------------------------------------------------------- 1 | source "https://rubygems.org" 2 | 3 | # Hello! This is where you manage which Jekyll version is used to run. 4 | # When you want to use a different version, change it below, save the 5 | # file and run `bundle install`. Run Jekyll with `bundle exec`, like so: 6 | # 7 | # bundle exec jekyll serve 8 | # 9 | # This will help ensure the proper Jekyll version is running. 10 | # Happy Jekylling! 11 | 12 | # gem "github-pages", group: :jekyll_plugins 13 | 14 | # To upgrade, run `bundle update`. 15 | 16 | gem "jekyll" 17 | gem "minimal-mistakes-jekyll" 18 | 19 | # The following plugins are automatically loaded by the theme-gem: 20 | # gem "jekyll-paginate" 21 | # gem "jekyll-sitemap" 22 | # gem "jekyll-gist" 23 | # gem "jekyll-feed" 24 | # gem "jekyll-include-cache" 25 | # 26 | # If you have any other plugins, put them here! 27 | group :jekyll_plugins do 28 | end -------------------------------------------------------------------------------- /Gemfile.lock: -------------------------------------------------------------------------------- 1 | GEM 2 | remote: https://rubygems.org/ 3 | specs: 4 | addressable (2.7.0) 5 | public_suffix (>= 2.0.2, < 5.0) 6 | colorator (1.1.0) 7 | concurrent-ruby (1.1.6) 8 | em-websocket (0.5.1) 9 | eventmachine (>= 0.12.9) 10 | http_parser.rb (~> 0.6.0) 11 | eventmachine (1.2.7) 12 | faraday (1.0.0) 13 | multipart-post (>= 1.2, < 3) 14 | ffi (1.12.2) 15 | forwardable-extended (2.6.0) 16 | http_parser.rb (0.6.0) 17 | i18n (1.8.2) 18 | concurrent-ruby (~> 1.0) 19 | jekyll (4.0.0) 20 | addressable (~> 2.4) 21 | colorator (~> 1.0) 22 | em-websocket (~> 0.5) 23 | i18n (>= 0.9.5, < 2) 24 | jekyll-sass-converter (~> 2.0) 25 | jekyll-watch (~> 2.0) 26 | kramdown (~> 2.1) 27 | kramdown-parser-gfm (~> 1.0) 28 | liquid (~> 4.0) 29 | mercenary (~> 0.3.3) 30 | pathutil (~> 0.9) 31 | rouge (~> 3.0) 32 | safe_yaml (~> 1.0) 33 | terminal-table (~> 1.8) 34 | jekyll-feed (0.13.0) 35 | jekyll (>= 3.7, < 5.0) 36 | jekyll-gist (1.5.0) 37 | octokit (~> 4.2) 38 | jekyll-include-cache (0.2.0) 39 | jekyll (>= 3.7, < 5.0) 40 | jekyll-paginate (1.1.0) 41 | jekyll-sass-converter (2.1.0) 42 | sassc (> 2.0.1, < 3.0) 43 | jekyll-sitemap (1.4.0) 44 | jekyll (>= 3.7, < 5.0) 45 | jekyll-watch (2.2.1) 46 | listen (~> 3.0) 47 | kramdown (2.3.1) 48 | rexml 49 | kramdown-parser-gfm (1.1.0) 50 | kramdown (~> 2.0) 51 | liquid (4.0.3) 52 | listen (3.2.1) 53 | rb-fsevent (~> 0.10, >= 0.10.3) 54 | rb-inotify (~> 0.9, >= 0.9.10) 55 | mercenary (0.3.6) 56 | minimal-mistakes-jekyll (4.18.1) 57 | jekyll (>= 3.6, < 5.0) 58 | jekyll-feed (~> 0.1) 59 | jekyll-gist (~> 1.5) 60 | jekyll-include-cache (~> 0.1) 61 | jekyll-paginate (~> 1.1) 62 | jekyll-sitemap (~> 1.3) 63 | multipart-post (2.1.1) 64 | octokit (4.16.0) 65 | faraday (>= 0.9) 66 | sawyer (~> 0.8.0, >= 0.5.3) 67 | pathutil (0.16.2) 68 | forwardable-extended (~> 2.6) 69 | public_suffix (4.0.3) 70 | rb-fsevent (0.10.3) 71 | rb-inotify (0.10.1) 72 | ffi (~> 1.0) 73 | rexml (3.2.5) 74 | rouge (3.16.0) 75 | safe_yaml (1.0.5) 76 | sassc (2.2.1) 77 | ffi (~> 1.9) 78 | sawyer (0.8.2) 79 | addressable (>= 2.3.5) 80 | faraday (> 0.8, < 2.0) 81 | terminal-table (1.8.0) 82 | unicode-display_width (~> 1.1, >= 1.1.1) 83 | unicode-display_width (1.6.1) 84 | 85 | PLATFORMS 86 | ruby 87 | 88 | DEPENDENCIES 89 | jekyll 90 | minimal-mistakes-jekyll 91 | 92 | BUNDLED WITH 93 | 2.1.3 94 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | Attribution-ShareAlike 4.0 International 2 | 3 | ======================================================================= 4 | 5 | Creative Commons Corporation ("Creative Commons") is not a law firm and 6 | does not provide legal services or legal advice. Distribution of 7 | Creative Commons public licenses does not create a lawyer-client or 8 | other relationship. Creative Commons makes its licenses and related 9 | information available on an "as-is" basis. Creative Commons gives no 10 | warranties regarding its licenses, any material licensed under their 11 | terms and conditions, or any related information. Creative Commons 12 | disclaims all liability for damages resulting from their use to the 13 | fullest extent possible. 14 | 15 | Using Creative Commons Public Licenses 16 | 17 | Creative Commons public licenses provide a standard set of terms and 18 | conditions that creators and other rights holders may use to share 19 | original works of authorship and other material subject to copyright 20 | and certain other rights specified in the public license below. The 21 | following considerations are for informational purposes only, are not 22 | exhaustive, and do not form part of our licenses. 23 | 24 | Considerations for licensors: Our public licenses are 25 | intended for use by those authorized to give the public 26 | permission to use material in ways otherwise restricted by 27 | copyright and certain other rights. Our licenses are 28 | irrevocable. Licensors should read and understand the terms 29 | and conditions of the license they choose before applying it. 30 | Licensors should also secure all rights necessary before 31 | applying our licenses so that the public can reuse the 32 | material as expected. Licensors should clearly mark any 33 | material not subject to the license. This includes other CC- 34 | licensed material, or material used under an exception or 35 | limitation to copyright. More considerations for licensors: 36 | wiki.creativecommons.org/Considerations_for_licensors 37 | 38 | Considerations for the public: By using one of our public 39 | licenses, a licensor grants the public permission to use the 40 | licensed material under specified terms and conditions. If 41 | the licensor's permission is not necessary for any reason--for 42 | example, because of any applicable exception or limitation to 43 | copyright--then that use is not regulated by the license. Our 44 | licenses grant only permissions under copyright and certain 45 | other rights that a licensor has authority to grant. Use of 46 | the licensed material may still be restricted for other 47 | reasons, including because others have copyright or other 48 | rights in the material. A licensor may make special requests, 49 | such as asking that all changes be marked or described. 50 | Although not required by our licenses, you are encouraged to 51 | respect those requests where reasonable. More_considerations 52 | for the public: 53 | wiki.creativecommons.org/Considerations_for_licensees 54 | 55 | ======================================================================= 56 | 57 | Creative Commons Attribution-ShareAlike 4.0 International Public 58 | License 59 | 60 | By exercising the Licensed Rights (defined below), You accept and agree 61 | to be bound by the terms and conditions of this Creative Commons 62 | Attribution-ShareAlike 4.0 International Public License ("Public 63 | License"). To the extent this Public License may be interpreted as a 64 | contract, You are granted the Licensed Rights in consideration of Your 65 | acceptance of these terms and conditions, and the Licensor grants You 66 | such rights in consideration of benefits the Licensor receives from 67 | making the Licensed Material available under these terms and 68 | conditions. 69 | 70 | 71 | Section 1 -- Definitions. 72 | 73 | a. Adapted Material means material subject to Copyright and Similar 74 | Rights that is derived from or based upon the Licensed Material 75 | and in which the Licensed Material is translated, altered, 76 | arranged, transformed, or otherwise modified in a manner requiring 77 | permission under the Copyright and Similar Rights held by the 78 | Licensor. For purposes of this Public License, where the Licensed 79 | Material is a musical work, performance, or sound recording, 80 | Adapted Material is always produced where the Licensed Material is 81 | synched in timed relation with a moving image. 82 | 83 | b. Adapter's License means the license You apply to Your Copyright 84 | and Similar Rights in Your contributions to Adapted Material in 85 | accordance with the terms and conditions of this Public License. 86 | 87 | c. BY-SA Compatible License means a license listed at 88 | creativecommons.org/compatiblelicenses, approved by Creative 89 | Commons as essentially the equivalent of this Public License. 90 | 91 | d. Copyright and Similar Rights means copyright and/or similar rights 92 | closely related to copyright including, without limitation, 93 | performance, broadcast, sound recording, and Sui Generis Database 94 | Rights, without regard to how the rights are labeled or 95 | categorized. For purposes of this Public License, the rights 96 | specified in Section 2(b)(1)-(2) are not Copyright and Similar 97 | Rights. 98 | 99 | e. Effective Technological Measures means those measures that, in the 100 | absence of proper authority, may not be circumvented under laws 101 | fulfilling obligations under Article 11 of the WIPO Copyright 102 | Treaty adopted on December 20, 1996, and/or similar international 103 | agreements. 104 | 105 | f. Exceptions and Limitations means fair use, fair dealing, and/or 106 | any other exception or limitation to Copyright and Similar Rights 107 | that applies to Your use of the Licensed Material. 108 | 109 | g. License Elements means the license attributes listed in the name 110 | of a Creative Commons Public License. The License Elements of this 111 | Public License are Attribution and ShareAlike. 112 | 113 | h. Licensed Material means the artistic or literary work, database, 114 | or other material to which the Licensor applied this Public 115 | License. 116 | 117 | i. Licensed Rights means the rights granted to You subject to the 118 | terms and conditions of this Public License, which are limited to 119 | all Copyright and Similar Rights that apply to Your use of the 120 | Licensed Material and that the Licensor has authority to license. 121 | 122 | j. Licensor means the individual(s) or entity(ies) granting rights 123 | under this Public License. 124 | 125 | k. Share means to provide material to the public by any means or 126 | process that requires permission under the Licensed Rights, such 127 | as reproduction, public display, public performance, distribution, 128 | dissemination, communication, or importation, and to make material 129 | available to the public including in ways that members of the 130 | public may access the material from a place and at a time 131 | individually chosen by them. 132 | 133 | l. Sui Generis Database Rights means rights other than copyright 134 | resulting from Directive 96/9/EC of the European Parliament and of 135 | the Council of 11 March 1996 on the legal protection of databases, 136 | as amended and/or succeeded, as well as other essentially 137 | equivalent rights anywhere in the world. 138 | 139 | m. You means the individual or entity exercising the Licensed Rights 140 | under this Public License. Your has a corresponding meaning. 141 | 142 | 143 | Section 2 -- Scope. 144 | 145 | a. License grant. 146 | 147 | 1. Subject to the terms and conditions of this Public License, 148 | the Licensor hereby grants You a worldwide, royalty-free, 149 | non-sublicensable, non-exclusive, irrevocable license to 150 | exercise the Licensed Rights in the Licensed Material to: 151 | 152 | a. reproduce and Share the Licensed Material, in whole or 153 | in part; and 154 | 155 | b. produce, reproduce, and Share Adapted Material. 156 | 157 | 2. Exceptions and Limitations. For the avoidance of doubt, where 158 | Exceptions and Limitations apply to Your use, this Public 159 | License does not apply, and You do not need to comply with 160 | its terms and conditions. 161 | 162 | 3. Term. The term of this Public License is specified in Section 163 | 6(a). 164 | 165 | 4. Media and formats; technical modifications allowed. The 166 | Licensor authorizes You to exercise the Licensed Rights in 167 | all media and formats whether now known or hereafter created, 168 | and to make technical modifications necessary to do so. The 169 | Licensor waives and/or agrees not to assert any right or 170 | authority to forbid You from making technical modifications 171 | necessary to exercise the Licensed Rights, including 172 | technical modifications necessary to circumvent Effective 173 | Technological Measures. For purposes of this Public License, 174 | simply making modifications authorized by this Section 2(a) 175 | (4) never produces Adapted Material. 176 | 177 | 5. Downstream recipients. 178 | 179 | a. Offer from the Licensor -- Licensed Material. Every 180 | recipient of the Licensed Material automatically 181 | receives an offer from the Licensor to exercise the 182 | Licensed Rights under the terms and conditions of this 183 | Public License. 184 | 185 | b. Additional offer from the Licensor -- Adapted Material. 186 | Every recipient of Adapted Material from You 187 | automatically receives an offer from the Licensor to 188 | exercise the Licensed Rights in the Adapted Material 189 | under the conditions of the Adapter's License You apply. 190 | 191 | c. No downstream restrictions. You may not offer or impose 192 | any additional or different terms or conditions on, or 193 | apply any Effective Technological Measures to, the 194 | Licensed Material if doing so restricts exercise of the 195 | Licensed Rights by any recipient of the Licensed 196 | Material. 197 | 198 | 6. No endorsement. Nothing in this Public License constitutes or 199 | may be construed as permission to assert or imply that You 200 | are, or that Your use of the Licensed Material is, connected 201 | with, or sponsored, endorsed, or granted official status by, 202 | the Licensor or others designated to receive attribution as 203 | provided in Section 3(a)(1)(A)(i). 204 | 205 | b. Other rights. 206 | 207 | 1. Moral rights, such as the right of integrity, are not 208 | licensed under this Public License, nor are publicity, 209 | privacy, and/or other similar personality rights; however, to 210 | the extent possible, the Licensor waives and/or agrees not to 211 | assert any such rights held by the Licensor to the limited 212 | extent necessary to allow You to exercise the Licensed 213 | Rights, but not otherwise. 214 | 215 | 2. Patent and trademark rights are not licensed under this 216 | Public License. 217 | 218 | 3. To the extent possible, the Licensor waives any right to 219 | collect royalties from You for the exercise of the Licensed 220 | Rights, whether directly or through a collecting society 221 | under any voluntary or waivable statutory or compulsory 222 | licensing scheme. In all other cases the Licensor expressly 223 | reserves any right to collect such royalties. 224 | 225 | 226 | Section 3 -- License Conditions. 227 | 228 | Your exercise of the Licensed Rights is expressly made subject to the 229 | following conditions. 230 | 231 | a. Attribution. 232 | 233 | 1. If You Share the Licensed Material (including in modified 234 | form), You must: 235 | 236 | a. retain the following if it is supplied by the Licensor 237 | with the Licensed Material: 238 | 239 | i. identification of the creator(s) of the Licensed 240 | Material and any others designated to receive 241 | attribution, in any reasonable manner requested by 242 | the Licensor (including by pseudonym if 243 | designated); 244 | 245 | ii. a copyright notice; 246 | 247 | iii. a notice that refers to this Public License; 248 | 249 | iv. a notice that refers to the disclaimer of 250 | warranties; 251 | 252 | v. a URI or hyperlink to the Licensed Material to the 253 | extent reasonably practicable; 254 | 255 | b. indicate if You modified the Licensed Material and 256 | retain an indication of any previous modifications; and 257 | 258 | c. indicate the Licensed Material is licensed under this 259 | Public License, and include the text of, or the URI or 260 | hyperlink to, this Public License. 261 | 262 | 2. You may satisfy the conditions in Section 3(a)(1) in any 263 | reasonable manner based on the medium, means, and context in 264 | which You Share the Licensed Material. For example, it may be 265 | reasonable to satisfy the conditions by providing a URI or 266 | hyperlink to a resource that includes the required 267 | information. 268 | 269 | 3. If requested by the Licensor, You must remove any of the 270 | information required by Section 3(a)(1)(A) to the extent 271 | reasonably practicable. 272 | 273 | b. ShareAlike. 274 | 275 | In addition to the conditions in Section 3(a), if You Share 276 | Adapted Material You produce, the following conditions also apply. 277 | 278 | 1. The Adapter's License You apply must be a Creative Commons 279 | license with the same License Elements, this version or 280 | later, or a BY-SA Compatible License. 281 | 282 | 2. You must include the text of, or the URI or hyperlink to, the 283 | Adapter's License You apply. You may satisfy this condition 284 | in any reasonable manner based on the medium, means, and 285 | context in which You Share Adapted Material. 286 | 287 | 3. You may not offer or impose any additional or different terms 288 | or conditions on, or apply any Effective Technological 289 | Measures to, Adapted Material that restrict exercise of the 290 | rights granted under the Adapter's License You apply. 291 | 292 | 293 | Section 4 -- Sui Generis Database Rights. 294 | 295 | Where the Licensed Rights include Sui Generis Database Rights that 296 | apply to Your use of the Licensed Material: 297 | 298 | a. for the avoidance of doubt, Section 2(a)(1) grants You the right 299 | to extract, reuse, reproduce, and Share all or a substantial 300 | portion of the contents of the database; 301 | 302 | b. if You include all or a substantial portion of the database 303 | contents in a database in which You have Sui Generis Database 304 | Rights, then the database in which You have Sui Generis Database 305 | Rights (but not its individual contents) is Adapted Material, 306 | 307 | including for purposes of Section 3(b); and 308 | c. You must comply with the conditions in Section 3(a) if You Share 309 | all or a substantial portion of the contents of the database. 310 | 311 | For the avoidance of doubt, this Section 4 supplements and does not 312 | replace Your obligations under this Public License where the Licensed 313 | Rights include other Copyright and Similar Rights. 314 | 315 | 316 | Section 5 -- Disclaimer of Warranties and Limitation of Liability. 317 | 318 | a. UNLESS OTHERWISE SEPARATELY UNDERTAKEN BY THE LICENSOR, TO THE 319 | EXTENT POSSIBLE, THE LICENSOR OFFERS THE LICENSED MATERIAL AS-IS 320 | AND AS-AVAILABLE, AND MAKES NO REPRESENTATIONS OR WARRANTIES OF 321 | ANY KIND CONCERNING THE LICENSED MATERIAL, WHETHER EXPRESS, 322 | IMPLIED, STATUTORY, OR OTHER. THIS INCLUDES, WITHOUT LIMITATION, 323 | WARRANTIES OF TITLE, MERCHANTABILITY, FITNESS FOR A PARTICULAR 324 | PURPOSE, NON-INFRINGEMENT, ABSENCE OF LATENT OR OTHER DEFECTS, 325 | ACCURACY, OR THE PRESENCE OR ABSENCE OF ERRORS, WHETHER OR NOT 326 | KNOWN OR DISCOVERABLE. WHERE DISCLAIMERS OF WARRANTIES ARE NOT 327 | ALLOWED IN FULL OR IN PART, THIS DISCLAIMER MAY NOT APPLY TO YOU. 328 | 329 | b. TO THE EXTENT POSSIBLE, IN NO EVENT WILL THE LICENSOR BE LIABLE 330 | TO YOU ON ANY LEGAL THEORY (INCLUDING, WITHOUT LIMITATION, 331 | NEGLIGENCE) OR OTHERWISE FOR ANY DIRECT, SPECIAL, INDIRECT, 332 | INCIDENTAL, CONSEQUENTIAL, PUNITIVE, EXEMPLARY, OR OTHER LOSSES, 333 | COSTS, EXPENSES, OR DAMAGES ARISING OUT OF THIS PUBLIC LICENSE OR 334 | USE OF THE LICENSED MATERIAL, EVEN IF THE LICENSOR HAS BEEN 335 | ADVISED OF THE POSSIBILITY OF SUCH LOSSES, COSTS, EXPENSES, OR 336 | DAMAGES. WHERE A LIMITATION OF LIABILITY IS NOT ALLOWED IN FULL OR 337 | IN PART, THIS LIMITATION MAY NOT APPLY TO YOU. 338 | 339 | c. The disclaimer of warranties and limitation of liability provided 340 | above shall be interpreted in a manner that, to the extent 341 | possible, most closely approximates an absolute disclaimer and 342 | waiver of all liability. 343 | 344 | 345 | Section 6 -- Term and Termination. 346 | 347 | a. This Public License applies for the term of the Copyright and 348 | Similar Rights licensed here. However, if You fail to comply with 349 | this Public License, then Your rights under this Public License 350 | terminate automatically. 351 | 352 | b. Where Your right to use the Licensed Material has terminated under 353 | Section 6(a), it reinstates: 354 | 355 | 1. automatically as of the date the violation is cured, provided 356 | it is cured within 30 days of Your discovery of the 357 | violation; or 358 | 359 | 2. upon express reinstatement by the Licensor. 360 | 361 | For the avoidance of doubt, this Section 6(b) does not affect any 362 | right the Licensor may have to seek remedies for Your violations 363 | of this Public License. 364 | 365 | c. For the avoidance of doubt, the Licensor may also offer the 366 | Licensed Material under separate terms or conditions or stop 367 | distributing the Licensed Material at any time; however, doing so 368 | will not terminate this Public License. 369 | 370 | d. Sections 1, 5, 6, 7, and 8 survive termination of this Public 371 | License. 372 | 373 | 374 | Section 7 -- Other Terms and Conditions. 375 | 376 | a. The Licensor shall not be bound by any additional or different 377 | terms or conditions communicated by You unless expressly agreed. 378 | 379 | b. Any arrangements, understandings, or agreements regarding the 380 | Licensed Material not stated herein are separate from and 381 | independent of the terms and conditions of this Public License. 382 | 383 | 384 | Section 8 -- Interpretation. 385 | 386 | a. For the avoidance of doubt, this Public License does not, and 387 | shall not be interpreted to, reduce, limit, restrict, or impose 388 | conditions on any use of the Licensed Material that could lawfully 389 | be made without permission under this Public License. 390 | 391 | b. To the extent possible, if any provision of this Public License is 392 | deemed unenforceable, it shall be automatically reformed to the 393 | minimum extent necessary to make it enforceable. If the provision 394 | cannot be reformed, it shall be severed from this Public License 395 | without affecting the enforceability of the remaining terms and 396 | conditions. 397 | 398 | c. No term or condition of this Public License will be waived and no 399 | failure to comply consented to unless expressly agreed to by the 400 | Licensor. 401 | 402 | d. Nothing in this Public License constitutes or may be interpreted 403 | as a limitation upon, or waiver of, any privileges and immunities 404 | that apply to the Licensor or You, including from the legal 405 | processes of any jurisdiction or authority. 406 | 407 | 408 | ======================================================================= 409 | 410 | Creative Commons is not a party to its public 411 | licenses. Notwithstanding, Creative Commons may elect to apply one of 412 | its public licenses to material it publishes and in those instances 413 | will be considered the “Licensor.” The text of the Creative Commons 414 | public licenses is dedicated to the public domain under the CC0 Public 415 | Domain Dedication. Except for the limited purpose of indicating that 416 | material is shared under a Creative Commons public license or as 417 | otherwise permitted by the Creative Commons policies published at 418 | creativecommons.org/policies, Creative Commons does not authorize the 419 | use of the trademark "Creative Commons" or any other trademark or logo 420 | of Creative Commons without its prior written consent including, 421 | without limitation, in connection with any unauthorized modifications 422 | to any of its public licenses or any other arrangements, 423 | understandings, or agreements concerning use of licensed material. For 424 | the avoidance of doubt, this paragraph does not form part of the 425 | public licenses. 426 | 427 | Creative Commons may be contacted at creativecommons.org. -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Domain-Driven Design Heuristics 2 | 3 | This is the repo for the site [Domain-Driven Design Heuristics](https://dddheuristics.com) 4 | 5 | # How it works 6 | 7 | This sites works with jekyll trough a github repo linked with netlify. You can fork the github repo [here](https://github.com/Baasie/domain-driven-design-heuristics) and create a pull request of your own heuristics. 8 | 9 | To work with Jekyll check out the [Jekyll Site](https://jekyllrb.com/) 10 | 11 | # Adding your own heuristics 12 | 13 | You can add your own heuristics as a markdown file under the respective _XXXX-heuristics directory. 14 | 15 | Not everyone uses github so alternatively you can send your heuristic in an email to submit@dddheuristic.com. 16 | 17 | # Writing, Remembering, and Sharing Design Heuristics 18 | 19 | For more information please read about how to write Heuristics Rebecca her article [Writing, Remembering, and Sharing Design Heuristics](http://wirfs-brock.com/blog/2019/04/12/writing/) 20 | 21 | There are some constraint when submitting a heuristic, you need to use at least the follow template: 22 | 23 | ## Template 24 | 25 | ``` markdown 26 | --- 27 | title: {The title of the heuristic} 28 | excerpt: {Summary of Problem or the question that the heuristic solves} 29 | tags: {tags seperated by space, fill in what you think is best} 30 | authors: {the authors as a yaml list} 31 | submitter: {The submitter} (optional) 32 | --- 33 | 34 | Example: 35 | 36 | --- 37 | title: "Heuristic" 38 | excerpt: "When I am faced with a problem, what do I do?" 39 | tags: Aggregate Bounded-Context socio-technical-systems 40 | authors: 41 | - Cindy 42 | - John 43 | --- 44 | 45 | or 46 | 47 | --- 48 | title: "Heuristic" 49 | excerpt: "When I am faced with a problem, what do I do?" 50 | tags: Aggregate Bounded-Context socio-technical-systems 51 | authors: Cindy 52 | submitter: Gert 53 | --- 54 | 55 | ``` 56 | 57 | You can fill in the rest the way you like it, but here are two examples from Rebecca her article 58 | 59 | ### Quick Heuristic from QHE cards 60 | 61 | ``` markdown 62 | --- 63 | title: {The title of the heuristic} 64 | excerpt: {Summary of Problem or the question that the heuristic solves} 65 | tags: {tags seperated by space, fill in what you think is best} 66 | authors: {the authors as a yaml list} 67 | submitter: {The submitter} (optional) 68 | --- 69 | 70 | # Short description 71 | A short description of the heuristics 72 | 73 | # Examples 74 | Give some examples 75 | 76 | ``` 77 | 78 | ### From QHE card to a Heuristic gist: 79 | 80 | ``` markdown 81 | --- 82 | title: {The title of the heuristic} 83 | excerpt: {Summary of Problem or the question that the heuristic solves} 84 | tags: {tags seperated by space, fill in what you think is best} 85 | authors: {the authors as a yaml list} 86 | submitter: {The submitter} (optional) 87 | --- 88 | 89 | # Description 90 | A description of the heuristics 91 | 92 | # Summary of Solution 93 | The solution of the heuristic 94 | 95 | ``` 96 | 97 | # Contribute 98 | 99 | Any help is welcome and needed, if you have any feedback please feel free to either create pull requests or tickets or send us an email! 100 | -------------------------------------------------------------------------------- /_config.yml: -------------------------------------------------------------------------------- 1 | # Welcome to Jekyll! 2 | # 3 | # This config file is meant for settings that affect your entire site, values 4 | # which you are expected to set up once and rarely need to edit after that. 5 | # For technical reasons, this file is *NOT* reloaded automatically when you use 6 | # `jekyll serve`. If you change this file, please restart the server process. 7 | 8 | # Theme Settings 9 | # 10 | # Review documentation to determine if you should use `theme` or `remote_theme` 11 | # https://mmistakes.github.io/minimal-mistakes/docs/quick-start-guide/#installing-the-theme 12 | 13 | theme: minimal-mistakes-jekyll 14 | # remote_theme : "mmistakes/minimal-mistakes" 15 | minimal_mistakes_skin : "air" # "air", "aqua", "contrast", "dark", "dirt", "neon", "mint", "plum" "sunrise" 16 | 17 | 18 | # Site settings 19 | locale : "en-US" 20 | title : "Domain-Driven Design Heuristics" 21 | title_separator : "-" 22 | subtitle : "Part of virtualDDD.com" 23 | name : "Developed by Kenny Baas-Schwegler & Marco Heimeshoff" 24 | description : "Helpfull heuristics to use in your software design" 25 | url : "https://dddheuristics.com" 26 | baseurl : "" 27 | repository : # GitHub username/repo-name e.g. "mmistakes/minimal-mistakes" 28 | teaser : "/assets/images/kandinsky.jpg" # path of fallback teaser image, e.g. "/assets/images/500x300.png" 29 | logo : "/assets/images/vddd_logo_small.png" 30 | search : true 31 | masthead_title : "DDD Heuristics" 32 | breadcrumbs : true # true, false (default) 33 | words_per_minute : 200 34 | comments: 35 | provider : "disqus" # false (default), "disqus", "discourse", "facebook", "staticman", "staticman_v2", "utterances", "custom" 36 | disqus: 37 | shortname : "dddheuristics" 38 | 39 | # Social Sharing 40 | twitter: 41 | username : virtualDDD 42 | 43 | # Site Author 44 | author: 45 | name : "Virtual DDD" 46 | avatar : "/assets/images/blank-avatar.png" 47 | 48 | # Reading Files 49 | include: 50 | - .htaccess 51 | - _pages 52 | exclude: 53 | - "*.sublime-project" 54 | - "*.sublime-workspace" 55 | - vendor 56 | - .asset-cache 57 | - .bundle 58 | - .jekyll-assets-cache 59 | - .sass-cache 60 | - assets/js/plugins 61 | - assets/js/_main.js 62 | - assets/js/vendor 63 | - Capfile 64 | - CHANGELOG 65 | - config 66 | - Gemfile 67 | - Gruntfile.js 68 | - gulpfile.js 69 | - LICENSE 70 | - log 71 | - node_modules 72 | - package.json 73 | - Rakefile 74 | - README 75 | - tmp 76 | - /docs # ignore Minimal Mistakes /docs 77 | - /test # ignore Minimal Mistakes /test 78 | keep_files: 79 | - .git 80 | - .svn 81 | encoding: "utf-8" 82 | markdown_ext: "markdown,mkdown,mkdn,mkd,md" 83 | 84 | # Conversion 85 | markdown: kramdown 86 | highlighter: rouge 87 | lsi: false 88 | excerpt_separator: "\n\n" 89 | incremental: false 90 | 91 | # Markdown Processing 92 | kramdown: 93 | input: GFM 94 | hard_wrap: false 95 | auto_ids: true 96 | footnote_nr: 1 97 | entity_output: as_char 98 | toc_levels: 1..6 99 | smart_quotes: lsquo,rsquo,ldquo,rdquo 100 | enable_coderay: false 101 | 102 | # Sass/SCSS 103 | sass: 104 | sass_dir: _sass 105 | style: compressed # https://sass-lang.com/documentation/file.SASS_REFERENCE.html#output_style 106 | 107 | # Outputting 108 | timezone: Europe/Amsterdam # Timezone for blog posts and alike 109 | # paginate: 5 # amount of posts to show 110 | # paginate_path: /page:num/ 111 | permalink: pretty 112 | 113 | # Set plugins 114 | plugins: 115 | - jekyll-paginate 116 | - jekyll-sitemap 117 | - jekyll-gist 118 | - jekyll-feed 119 | - jekyll-include-cache 120 | 121 | # HTML Compression 122 | # - https://jch.penibelst.de/ 123 | compress_html: 124 | clippings: all 125 | ignore: 126 | envs: development 127 | 128 | # 5. Collections 129 | collections: 130 | guiding-heuristics: 131 | output: true 132 | permalink: /:collection/:path/ 133 | design-heuristics: 134 | permalink: /:collection/:path/ 135 | output: true 136 | value-based-heuristics: 137 | permalink: /:collection/:path/ 138 | output: true 139 | 140 | defaults: 141 | - scope: 142 | path: "" 143 | values: 144 | layout: single 145 | comments: true 146 | header: 147 | overlay_color: "#1a202c" 148 | overlay_filter: "0.65" 149 | overlay_image: /assets/images/kandinsky.jpg 150 | - scope: 151 | type: guiding-heuristics 152 | values: 153 | layout: heuristics 154 | sidebar: 155 | nav: "heuristics" 156 | - scope: 157 | type: design-heuristics 158 | values: 159 | layout: heuristics 160 | sidebar: 161 | nav: "heuristics" 162 | - scope: 163 | type: value-based-heuristics 164 | values: 165 | layout: heuristics 166 | sidebar: 167 | nav: "heuristics" 168 | -------------------------------------------------------------------------------- /_data/navigation.yml: -------------------------------------------------------------------------------- 1 | main: 2 | - title: "Home" 3 | url: / 4 | - title: "Heuristics" 5 | url: /heuristics/ 6 | - title: "Submit Heuristics" 7 | url: /submit/ 8 | - title: "VirtualDDD" 9 | url: https://virtualddd.com 10 | 11 | heuristics: 12 | - title: "Design Heuristics" 13 | children: 14 | - title: "All" 15 | url: /design-heuristics/ 16 | - title: "Align with business value" 17 | url: /align-with-business-value/ 18 | - title: "Guiding Heuristics" 19 | children: 20 | - title: "All" 21 | url: /guiding-heuristics/ 22 | - title: "EventStorming" 23 | url: /eventstorming/ 24 | - title: "Example Mapping" 25 | url: /example-mapping/ 26 | - title: "Remote EventStorming" 27 | url: /remote-eventstorming/ 28 | - title: "Value-based Heuristics" 29 | children: 30 | - title: "All" 31 | url: /value-based-heuristics/ 32 | -------------------------------------------------------------------------------- /_design-heuristics/a-bounded-context-should-keep-its-internal-details-private.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "A bounded context should keep its internal details private" 3 | excerpt: "" 4 | tags: design-heuristics 5 | authors: Mathias Verraes 6 | submitter: Kenny Baas-Schwegler 7 | --- 8 | 9 | # Short description 10 | 11 | If you are keeping monetary units in say 10 digits internally in a service, you would only pass out an amount in 2 digits precision because that’s all other consumers of the event would need 12 | 13 | # Examples 14 | 15 | # Context 16 | -------------------------------------------------------------------------------- /_design-heuristics/align-bounded-context-with-the-value-stream.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Align bounded context with the value stream" 3 | excerpt: "How do I design Bounded Contexts?" 4 | tags: design-heuristics bounded-context socio-technical-systems 5 | authors: Marco Consolaro 6 | --- 7 | 8 | # Short description 9 | 10 | Align bounded contexts in socio-technical systems to support the value stream of the business. Use these at a strategic level when you are in a position to understand the value stream of the business. 11 | 12 | # Examples 13 | For example, in an ecommerce company selling physical items online, the value stream activities include: 14 | 15 | * Acquiring (physically or remotely) the items to be sold 16 | * Describing their physical details (color, qualities, pictures and other information useful for their placement on the market) 17 | * Assessing and interacting to handle the quantity in stock 18 | * Creating and managing the mechanism for customers to browse the catalogue, place an order and pay, dispatch the items 19 | 20 | In parallel, there’s a marketing system to place advertisements, and after the sale is done, there will be some customer care functionality. This and all of the above are activities of the value stream. They can happen in parallel, and the stream might be somewhat complicated, but they can be carried on independently of one another. However, they have dependencies; for example, the system in charge of letting customers place an order obviously needs to know the stock of the available items – they are interconnected. 21 | 22 | # Context 23 | 24 | > _“If you can’t describe what you are doing as a process, you don’t know what you’re doing.”_ - William Edwards Deming 25 | 26 | ![Value stream](/assets/images/value-stream.png) 27 | 28 | There is a vast amount of literature about value streams and value stream mapping, but I feel that the key concepts to understand aren’t enhanced with more detail. From this point of view, the idea of the Lean value stream as a diagrammatic representation of the sequence of activities that an organization undertakes in order to produce an overall result for a customer, stakeholder or end-user is the key starting point. 29 | The activities of the flow are independent, but interconnected; this is one of the properties of a Complex System. Each activity performs different tasks in autonomy, but feeds information back to other parts of the System that are needed for the chain of value to progress to the next stage. 30 | 31 | In order to keep the overall entropy of the organization under control, the business must correctly separate and group these activities into independent but interconnected subsystems and optimize their communication. This is a crucial point. In the world of Domain-Driven Design, these subsystems are called _*bounded contexts.*_ 32 | 33 | ![Value stream and bounded context](/assets/images/value-stream-contexts.png) 34 | 35 | Since bounded contexts are high-level modules, there should also be among them a special focus on communication. Furthermore, given that to reach a good understanding we should move the focal point to the external system (as noted by Russell Ackoff), this explains why it is important to understand the value stream in order to design the best interaction flow between the bounded contexts. 36 | 37 | This logical, high-level view of the system is more important than the internals because it is the key to doing the right thing. And here the crucial point is finding the perfect balance between their independence and their interrelations, determining how to split them. What subtasks should be grouped together to form a bounded context, and what should be on their own? 38 | 39 | ![Bounded contexts and communication](/assets/images/value-stream-events.png) 40 | 41 | The answer is that it depends on the overall context – there is no silver bullet here either, sorry! But we have principles that can help with the inductive process of making decisions. 42 | For instance, we can see here the same forces in place that we have seen in Cohesion and Coupling: 43 | 44 | * Too much Cohesion: Keeping every task in one big bounded context would mean entangling the system, making it hard to change and scale, similar to the God class and Divergent Change code smells. 45 | * Too much Coupling: Splitting every task into its own bounded context would mean moving that complexity over the communication between them, generating an explosion of dependencies. Furthermore, the way to achieving independence is not free in a SOA environment; the infrastructural boundary must be created, deployed, maintained and monitored. 46 | 47 | >_“You have to choose where to pay the price of complexity. Because DDD is about reducing complexity in the software, the outcome is that you pay a price with respect to maintaining duplicate models and possibly duplicate data.”_ - Eric Evans 48 | 49 | ![Bounded contexts and teams](/assets/images/bounded-context.png) 50 | -------------------------------------------------------------------------------- /_design-heuristics/align-with-domain-experts.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Align with domain experts" 3 | excerpt: "" 4 | tags: design-heuristics 5 | authors: Nick Tune 6 | --- 7 | 8 | # Short description 9 | 10 | align boundaries with the parts of the domain where there are different domain experts (not different people but different domain skills/knowledge). 11 | 12 | # Examples 13 | 14 | # context 15 | 16 | We should align boundaries in sociotechnical systems with our business processes to minimise dependencies and promote sustainable development practices. 17 | -------------------------------------------------------------------------------- /_design-heuristics/align-with-evolutionary-stage.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Align with evolutionary stage (the Simon Wardley heuristic)" 3 | excerpt: "" 4 | tags: design-heuristics align-with-business-value 5 | authors: Nick Tune 6 | --- 7 | 8 | # Short description 9 | 10 | TBD 11 | 12 | # Examples 13 | 14 | 15 | # Context 16 | 17 | Use these at a strategic level when defining bounded context. When you want to seperate core domains from supporting and generic subdomains 18 | -------------------------------------------------------------------------------- /_design-heuristics/align-with-growth-strategy.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Align with growth strategy" 3 | excerpt: "" 4 | tags: design-heuristics align-with-business-value 5 | authors: Nick Tune 6 | --- 7 | 8 | # Short description 9 | 10 | Create seperate context for parts of the system business wants to scale up 11 | 12 | # Examples 13 | 14 | # Context 15 | 16 | Use these at a strategic level when defining bounded context. When you want to seperate core domains from supporting and generic subdomains 17 | -------------------------------------------------------------------------------- /_design-heuristics/align-with-historical-domain-boundaries.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Align with historical domain boundaries" 3 | excerpt: "" 4 | tags: design-heuristics 5 | authors: Nick Tune 6 | --- 7 | 8 | # Short description 9 | 10 | Look for parts of the domain which have not changed in a long time. 11 | 12 | # Examples 13 | 14 | A user inbox for keeping communication message to the customer, this almost never changes. 15 | 16 | # Context 17 | 18 | We should align boundaries in sociotechnical systems with our business processes to minimise dependencies and promote sustainable development practices. 19 | -------------------------------------------------------------------------------- /_design-heuristics/align-with-investment-strategy.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Align with investment strategy" 3 | excerpt: "" 4 | tags: design-heuristics align-with-business-value 5 | authors: Nick Tune 6 | --- 7 | 8 | # Short description 9 | 10 | Align boundries with the part of the system you want to invest the most time and improvements in the future. 11 | 12 | # Examples 13 | 14 | # Context 15 | 16 | Use these at a strategic level when defining bounded context. When you want to seperate core domains from supporting and generic subdomains 17 | -------------------------------------------------------------------------------- /_design-heuristics/align-with-key-revenue-streams.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Align with key revenue streams" 3 | excerpt: "" 4 | tags: design-heuristics align-with-business-value 5 | authors: Nick Tune 6 | --- 7 | 8 | # Short description 9 | 10 | Create bounded context for the parts of the system which currently generate the most money 11 | 12 | # Examples 13 | 14 | # Context 15 | 16 | Use these at a strategic level when defining bounded context. When you want to seperate core domains from supporting and generic subdomains 17 | -------------------------------------------------------------------------------- /_design-heuristics/align-with-rate-of-change.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Align with rate of change" 3 | excerpt: "" 4 | tags: design-heuristics 5 | authors: Nick Tune 6 | --- 7 | 8 | # Short description 9 | 10 | Group things that frequently change together to avoid coupling across boundaries. 11 | 12 | # Examples 13 | 14 | For instance a payment service, or a user profile service or an notification service. 15 | 16 | # Context 17 | 18 | We should align boundaries in sociotechnical systems with our business processes to minimise dependencies and promote sustainable development practices. 19 | -------------------------------------------------------------------------------- /_design-heuristics/align-with-source-of-change.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Align with source of change" 3 | excerpt: "" 4 | tags: design-heuristics 5 | authors: Nick Tune 6 | --- 7 | 8 | # Short description 9 | 10 | align boundaries with the people asking for changes because those people will care about concepts which are likely to be more closely related. 11 | 12 | # Examples 13 | 14 | separate business-to-business and business-to-consumer services because both customer segments will have different needs. 15 | 16 | # Context 17 | 18 | We should align boundaries in sociotechnical systems with our business processes to minimise dependencies and promote sustainable development practices. 19 | -------------------------------------------------------------------------------- /_design-heuristics/align-with-transactional-boundaries.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Align with transactional boundaries" 3 | excerpt: "" 4 | tags: design-heuristics 5 | authors: Nick Tune 6 | --- 7 | 8 | # Short description 9 | 10 | align boundaries with data which must always be immediately consistent. 11 | 12 | # Examples 13 | 14 | When a user reserve specific seats for a cinema those seats needs to stay reserved and unavailable for other users for a certain amount of time while the user pays. 15 | 16 | # Context 17 | 18 | We should align boundaries in sociotechnical systems with our business processes to minimise dependencies and promote sustainable development practices. 19 | -------------------------------------------------------------------------------- /_design-heuristics/build-software-for-disruptive-generic-subdomains-yourself.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Build software for disruptive generic subdomains yourself" 3 | excerpt: "When should we write software for generic domain ourself?" 4 | tags: design-heuristics align-with-business-value 5 | authors: Nick Tune 6 | --- 7 | 8 | # Short description 9 | 10 | Sometimes dependencies are so generic that you don't want to invest time in it and you want to buy them of the shelf: see [outsourced-generic-subdomains](Outsource generic subdomains) 11 | 12 | But if the market is potentially disruptive, then the bought system or SaaS solution might slow you down because of lack of innovation. 13 | 14 | # Examples 15 | 16 | The company that created slack 17 | 18 | # Context 19 | 20 | Use these at a strategic level when defining bounded context. When you want to seperate core domains from supporting and generic subdomains 21 | -------------------------------------------------------------------------------- /_design-heuristics/design-bounded-context-around-eventstorming-policies.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Design Bounded Contexts around EventStorming Policies" 3 | excerpt: "How do we design a bounded context?" 4 | tags: design-heuristics EventStorming 5 | authors: Kenny Baas-Schwegler 6 | --- 7 | 8 | # Short description 9 | 10 | From a process or design level EventStorming, design your bounded contexts around the purple sticky called a policy. 11 | 12 | # Examples 13 | 14 | * When a domain experts mentions: When this event happens we will start the reservation process. We can add a policy that can be names: Reservation process policy 15 | * Sometimes a policy is a long running process for instance a timer to cancel a reservation when the ustomer has not payed. You can design these within your bounded context instead of spanning between. 16 | 17 | # Context 18 | 19 | During process and design level EventStorming we want to design our bounded context. Since we usually take a customer journey or a product it can span multiple bounded contexts. -------------------------------------------------------------------------------- /_design-heuristics/design-bounded-context-by-looking-at-the-humans-during-big-picture-eventstorming.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Design bounded contexts by looking at the humans during a big picture EventStorming" 3 | excerpt: "How do we dissect bounded contexts?" 4 | tags: design-heuristics bounded-context socio-technical-systems 5 | authors: Alberto Brandolini 6 | submitter: Kenny Baas-Schwegler 7 | --- 8 | 9 | # Short description 10 | 11 | Different people are a great indicator of different needs, which means different models. Design a bounded context around the needs of different people. 12 | 13 | # Context 14 | 15 | Where people are during the exploration of a big picture eventstorming, is probably giving the simplest and powerful clue about different model 16 | distribution. Experts tend to spend most time hovering around the areas that they know better, to provide answers 17 | or to correct wrong stickies¹⁵ that they see on the paper roll. Alternatively, they comment around 18 | the areas that they care about, maybe because the current implementation is far from satisfactory. 19 | 20 | # Reference 21 | 22 | From [Domain-Driven Design: The First 15 Years - Discovering Bounded Contexts with EventStorming by Alberto Brandolini 55](https://leanpub.com/ddd_first_15_years) -------------------------------------------------------------------------------- /_design-heuristics/design-bounded-contexts-by-looking-at-the-one-way-flow-of-orange-sticky-notes-during-a-big-picture-eventstorming.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Design bounded contexts by looking at the one-way flow of orange sticky notes during a big picture EventStorming" 3 | excerpt: "How to design bounded contexts?" 4 | tags: design-heuristics bounded-context 5 | authors: Masoud Bahrami 6 | --- 7 | 8 | # Short description 9 | 10 | From a big picture EventStorming workshop, looking for one-way flow of orange stickies, and puth them in the same boundary. 11 | 12 | # Examples 13 | 14 | - A new hotel is created. 15 | - The hotel images were uploaded. 16 | - The hotel pricing is done. 17 | - The hotel pricing is approved. 18 | - The hotel marked as ready for reserve. 19 | - The room was reserved. 20 | - The room was released. 21 | 22 | # Context 23 | 24 | When a domain experts puts a train of orange sticky notes back to back on the wall in the same swimlane, this mean he/she is working on the same related concepts which allighn a business line in which he/she operates. -------------------------------------------------------------------------------- /_design-heuristics/design-for-replayability.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Design for replayability" 3 | excerpt: "" 4 | tags: design-heuristic 5 | authors: 6 | - Nick Tune 7 | - Kacper Gunia 8 | --- 9 | 10 | # Short description 11 | 12 | Design projections so that they can be easily replayed per stream or projection type. 13 | 14 | # Examples 15 | 16 | A particular read model requires a new field that wasn't captured previously. Changing the logic and replaying it will make the field available for already existing read models as well as for newly created ones. 17 | 18 | # context 19 | 20 | In Event-Driven architectures and particularly in Event-Sourcing + CQRS the "read" part of the system is a projection of the Event Stream. Design the infrastructure of the event delivery to projection handler so that it can be easily replayed when bugs are discovered or requirements changed. It is usually a good idea to be able to replay either subset of streams or all of them. -------------------------------------------------------------------------------- /_design-heuristics/isolate-high-leverage-shared-capabilities.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Isolate high-leverage shared capabilities" 3 | excerpt: "" 4 | tags: design-heuristics align-with-business-value 5 | authors: Nick Tune 6 | --- 7 | 8 | # Short description 9 | 10 | Create a shared bounded context that others bounded contexts in the company can use to avoid having to duplicate the logic in multiple contexts. Are there seperate concepts at play. Dependency management. Trading off dependencies. Local autonomy vs global consistency. 11 | 12 | Don't create a shared dependency unless there is enough benefit. The benefit is that several teams reuse the shared capability which gives them more time to focus on their core areas. 13 | 14 | # Examples 15 | 16 | In a large enterprise several teams might use capabilities like notifications with for instance emailing or texting. 17 | 18 | # Context 19 | 20 | Use these at a strategic level when defining bounded context. When you want to seperate core domains from supporting and generic subdomains 21 | -------------------------------------------------------------------------------- /_design-heuristics/keep-your-domain-model-decoupled-from-frameworks.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Keep your domain model decoupled from frameworks" 3 | excerpt: "How can I let my domain model be decoupled from technical complexity?" 4 | tags: design-heuristics 5 | authors: Kenny Baas-Schwegler 6 | --- 7 | 8 | # Short description 9 | 10 | The domain model is the core of our bounded context. When we implement the domain model we want the ability to keep this consistent with our ubiqituous language. We want the ability to quicly refactor this to represent our mind-model of our domain model. 11 | 12 | # Examples 13 | 14 | In java and C# you see the use of ORM mapping like JPA and Entity Framework in our domain model. This can quickly lead high coupling with our database domain. 15 | 16 | # Context 17 | 18 | When we implement domain models we want to seperate the domain model from other layers to keep the domain clean. We sometimes see the use of frameworks like ORM mapping in the domain model for easier use. This can lead to high coupling between the domain model and the database model, which we don't want. -------------------------------------------------------------------------------- /_design-heuristics/optimise-for-future-potential.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Optimise for future potential" 3 | excerpt: "" 4 | tags: design-heuristics align-with-business-value 5 | authors: Nick Tune 6 | --- 7 | 8 | # Short description 9 | 10 | Even is sometime is core now, keep it as a seperate boundry anyway. 11 | 12 | # Examples 13 | 14 | one option is to have a discovery context which have search catalog and recommendations. But if you know that one of those things is going to be a key part of the business in the future and you want to improve one of those things prematturly optimize so you can iterate on this bounded context faster. 15 | 16 | # Context 17 | 18 | Use these at a strategic level when defining bounded context. When you want to seperate core domains from supporting and generic subdomains 19 | -------------------------------------------------------------------------------- /_design-heuristics/organise-for-responsiveness-in-differentiator-capabilities.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Organise for responsiveness in differentiator capabilities" 3 | excerpt: "" 4 | tags: design-heuristics align-with-business-value 5 | authors: Nick Tune 6 | --- 7 | 8 | # Short description 9 | 10 | TBD 11 | 12 | # Examples 13 | 14 | # Context 15 | 16 | Use these at a strategic level when defining bounded context. When you want to seperate core domains from supporting and generic subdomains 17 | -------------------------------------------------------------------------------- /_design-heuristics/outsource-generic-subdomains.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Outsource generic subdomains" 3 | excerpt: "Should we write software for generic subdomains ourself?" 4 | tags: design-heuristics align-with-business-value 5 | authors: Nick Tune 6 | --- 7 | 8 | # Short description 9 | 10 | Sometimes dependencies are so generic that you don't want to invest time in it and you can either buy them off the shelf or use a SaaS functionality. 11 | 12 | You only oursource when there is enough competition in that market 13 | 14 | # Examples 15 | 16 | Payment providers like stripe, paypal etc. 17 | Usermanagement, single sign-on like AWS or oath.com 18 | 19 | # Context 20 | 21 | Use these at a strategic level when defining bounded context. When you want to seperate core domains from supporting and generic subdomains 22 | -------------------------------------------------------------------------------- /_design-heuristics/seperate-engagement-and-revenue.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Separate engagement and revenue" 3 | excerpt: "" 4 | tags: design-heuristics align-with-business-value 5 | authors: Nick Tune 6 | --- 7 | 8 | # Short description 9 | 10 | When looking for boundries you can group things that make money and things that don't make money but provide some value to the user. 11 | 12 | # Examples 13 | 14 | google has a search engine, but makes money out of ads. They don't get money from their users, but from selling ads. 15 | 16 | # Context 17 | 18 | Use these at a strategic level when defining bounded context. When you want to seperate core domains from supporting and generic subdomains 19 | -------------------------------------------------------------------------------- /_design-heuristics/use-orm-in-domain-model-when-rate-of-change-is-low.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Use ORM in your domain model when rate of change is low" 3 | excerpt: "When can it be appropiate to use ORM mapping in my domain model?" 4 | tags: design-heuristics 5 | authors: Kenny Baas-Schwegler 6 | --- 7 | 8 | # Short description 9 | 10 | When your domain model does not change quickly you can decide to use a ORM mapping framework (for instance: JPA, EntityFramework) in your domain. This way we don't need to create mapping between the domain model and the repository model. 11 | 12 | # Examples 13 | 14 | A user inbox for keeping communication message to the customer, this does not change that fast. 15 | 16 | # Context 17 | 18 | When we implement domain models with hexagonal or clean architecture we need to seperate the domain model from the repository model and create mappers. For small domains that don't change fast this can be a lot of work. -------------------------------------------------------------------------------- /_guiding-heuristics/always-write-gherkin.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Always write Gherkin" 3 | excerpt: "When should I formalise with the Gherkin script?" 4 | tags: guiding-heuristics behaviour-driven-development 5 | authors: Matt Wynne 6 | submitter: Kenny Baas-Schwegler 7 | --- 8 | 9 | # Short description 10 | 11 | You should always write Gherkin for the examples that you got our of the discovery phase. Writing the examples as Gherkin get's you new insights. You don't need to use it to automate. 12 | 13 | # Context 14 | 15 | When doing Behaviour-Driven Development we want to formalise our examples so we can possibly use these to automate them. -------------------------------------------------------------------------------- /_guiding-heuristics/eventstorming-add-minority-wisdom-to-decision.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "EventStorming: Add minority wisdom to decision" 3 | excerpt: "How do we wrap up a dot voting at a big picture EventStorming?" 4 | tags: guiding-heuristics eventstorming 5 | authors: Kenny Baas-Schwegler 6 | --- 7 | 8 | # Description 9 | 10 | 11 | When wrapping up a big picture EventStorming with a dot voting on hotspots or opportunities, we need to add minority wisdom to the decision made. Tell the people who did not vote on the majority decision that you are sorry. Then ask 'what do you need to also commit to that decision'. Add this wisdom (within the boundaries of the decision made) to the decision so that we made a collective autocratic decision, where everyone feels included. 12 | 13 | # Summary of the solution 14 | 15 | A big picture EventStorming can have a lot of hotspots and opportunities; the goal at the end is finding the [theory of constraint](https://en.wikipedia.org/wiki/Theory_of_constraints). We do this by asking the participants what they think is the biggest hotspot or opportunity to fix. However, the minority of people who did not decide for the winning decision might feel left out. They also might have wisdom we missed during our EventStorming session. So what can we learn from the people who did not vote on that decision, and how can we get buy-in from this group so that they won't resist when moving forward on it. What are their needs? -------------------------------------------------------------------------------- /_guiding-heuristics/eventstorming-add-more-detail-with-invisible-conversation.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "EventStorming: Add more details with invisible conversations." 3 | excerpt: "When do we have enough details in an EventStorming?" 4 | tags: guiding-heuristics eventstorming 5 | authors: Kenny Baas-Schwegler 6 | --- 7 | 8 | # Short description 9 | 10 | During a EventStorming we want to add more detail when the conversation is not visualised. If during a conversation the body language is turned towards the group instead of towards the the paper roll, then we need to add more details. 11 | 12 | # Examples 13 | 14 | 1. When someone is telling a story and is pointing towards stickies on the paper roll, we will have enough details. 15 | 2. When there is a discussion that is turned towards the group instead of pointing towards stickies on the paper roll, we need to add in more details 16 | 17 | # Context 18 | 19 | During an EventStorming session on any level, we want to make our conversations visible on the paper roll with stickies. During the whole durtion of the EventStorming we need to have enough detail so that there is a common understanding. -------------------------------------------------------------------------------- /_guiding-heuristics/eventstorming-ask-is-this-always-the-case-on-policy.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "EventStorming: Ask is this always the case on policy" 3 | excerpt: "How can we discover more edge cases during an EventStorming session?" 4 | tags: guiding-heuristics eventstorming 5 | authors: Kenny Baas-Schwegler 6 | --- 7 | 8 | # Description 9 | 10 | If we visualise a policy (Lilac sticky) during an EventStorming based on 'whenever this Domain Event happens we will do this action/command', always ask the question: Is this what we always do? 11 | 12 | # Summary of the solution 13 | 14 | > It is impossible for a person to learn 15 | > what they think they already know. 16 | > – Epictetus 17 | 18 | We can make a lot of assumptions during an EventStorming on process or design level. Policies, asl Alberto says, are great lie detectors. We can aks a lot of questions about them and there is almost always more to discover. 19 | -------------------------------------------------------------------------------- /_guiding-heuristics/eventstorming-do-big-picture-eventstorming-on-a-single-paper-roll.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "EventStorming: Do big picture EventStorming on a single paper roll" 3 | excerpt: "How many people can we have during an EventStorming?" 4 | tags: guiding-heuristics eventstorming 5 | authors: Kenny Baas-Schwegler 6 | --- 7 | 8 | # Description 9 | 10 | For a Big Picture EventStorming let all the participants share their domain events on a single paper roll. 11 | 12 | # Summary of the solution 13 | 14 | With a Big Picture EventStorming we want all participants to share their domain events on a single same paper roll. Usually we have around 20-30+ people as long as their is enough facilitators. Which is different from a process or design level EventStroming where we split and merge above 7 people. 15 | -------------------------------------------------------------------------------- /_guiding-heuristics/eventstorming-dont-be-shy-on-duplicating-stickies.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "EventStorming: Don't be shy on duplicating stickies" 3 | excerpt: "When running EventStorming workshops, duplication is not evil." 4 | tags: guiding-heuristics eventstorming 5 | authors: Cédric Pontet 6 | --- 7 | 8 | # Description 9 | 10 | People, especially developers, usually abhor duplication. But when running an EventStorming workshop, duplicating sticky notes is not necessarily evil, and even recommended. 11 | 12 | # Summary of the solution 13 | 14 | The goal of an EventStorming workshop, whether you run a Big Picture, Process Modeling, or Software Design session, is to be as explicit as possible and enforce the timeline. So it is not a problem to see the same *Event* occur twice, three times or even more, on the design surface. It's even recommended in order to gain clarity and avoid going back on the timeline. 15 | 16 | Same goes for *People*, *Systems*, *Aggregates* and *Policies*. If they are involved at different moments in the process, then duplicate the sticky note to keep the timeline clean and enforce the flow. 17 | -------------------------------------------------------------------------------- /_guiding-heuristics/eventstorming-dont-fill-in-the-gaps.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "EventStorming: Don't fill in the gaps" 3 | excerpt: "How can we get new insight during an EventStorming session?" 4 | tags: guiding-heuristics eventstorming 5 | authors: Kenny Baas-Schwegler 6 | --- 7 | 8 | # Description 9 | 10 | If we want to generate new insight during an eventstorming, we must delay to structure the EventStorm. Do this by leaving gaps between the patterns so that people can use there own perception to fill these in. 11 | 12 | # Summary of the solution 13 | 14 | When you give clear, concrete structured answers, in this case when you start using the colour coding in a strict way, people won't get new insights. People will only get new insights and an epiphany when they fill in gaps themselve and patterns from the chaos start to emerge for them. -------------------------------------------------------------------------------- /_guiding-heuristics/eventstorming-emerging-pivotal-events-for-a-big-picture.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "EventStorming: Emerging pivotal events for a Big Picture" 3 | excerpt: "How can we start structuring a Big Picture Eventstorming after a chaotic exploration?" 4 | tags: guiding-heuristics eventstorming remote-eventstorming remote-workshop 5 | authors: Kenny Baas-Schwegler 6 | --- 7 | 8 | # Description 9 | 10 | After a chaotic exploration for a big picture eventstorming, we can have over 2-300 domain events on our paper roll. To start sorting and structuring these domain events, we use a pattern called Pivotal or key events. These are events that the group and especially the domain events recognise in the flow that means a lot to them. Something that you can say, from this point onwards all the other stuff can happen. The trouble is, sometimes people find it hard to pinpoint them already. Of course, we should tell that they can always be changed; only people sometimes feel such a decision can be permanent. 11 | 12 | # Summary of the solution 13 | 14 | We can use the emerging pivotal events that we can take a group of events and start enforcing the timeline from there. Using the emerging pivotal events, we don't lock ourself to a more definitive decision, which eases some people but can unblock, move on and start sorting the domain events on the timeline, enforcing the timeline. 15 | 16 | ![Emerging pivotal events](/assets/images/emerging-pivotal-events.png) 17 | 18 | # remote eventstorming 19 | 20 | In a remote Big Picture eventstorming we can put people in break-out rooms based on these pivotal events. What we observe is that even then it get's even more important not to lock down to much on these pivotal events. -------------------------------------------------------------------------------- /_guiding-heuristics/eventstorming-explore-what-if-scenarios.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "EventStorming: Explore what-if scenarios" 3 | excerpt: "Explore all the edge cases and what happens when things go wrong." 4 | tags: guiding-heuristics eventstorming 5 | authors: Cédric Pontet 6 | --- 7 | 8 | # Description 9 | 10 | At the beginning of an EventStorming session, we tend to focus on the happy path, what happens when things go well and we reach the end of our process without an issue. But life is not that easy! We all know that sometimes things don't go according to the initial plan. 11 | 12 | # Summary of the solution 13 | 14 | After you figure out the nominal scenario, focus on other branches. What happens when this thing does not work? What if the API call to that *External System* fails? What if there is not enough money on the bank account? 15 | 16 | Don't explore all branches at once, or you will get lost. Every time a new *what if* branch comes up, write it down as a Hot Spot (ping/magenta sticky) to keep track of it, then continue with the branch you are on. Once you are done exploring your branch, come back to the most interesting *what if* scenario and start exploring it. You might eventually decide that it is not worth exploring, but at least you know it exists. 17 | -------------------------------------------------------------------------------- /_guiding-heuristics/eventstorming-introduce-new-colours-iteratively.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "EventStorming: Introduce new colours iteratively" 3 | excerpt: "How do we introduce new colours during an EventStorming?" 4 | tags: guiding-heuristics eventstorming 5 | authors: Kenny Baas-Schwegler 6 | --- 7 | 8 | # Short description 9 | 10 | During an EventStorming session the group starts with a chaotic exploration of all the Domain Events. The next step is enforcing the timeline and create a consistent timeline. At this point new concept can pop up, like policies, actions, information, business rule (yellow). We can mark them as a hotspot, but we can also introduce the colours iteratively to the group. 11 | 12 | ![EventStorming colour coding pattern](/assets/images/eventstorming-colour-coding.jpg) 13 | 14 | # Examples 15 | 16 | 1. When there is a discussion popping up about two domain events as outcomes from the same action, you need a business rule (yellow) in between. 17 | 2. When as an outcome from a domain event the domein expert explicitly uses a domain concept. For instance when a payment is accepted we need to start process X. 18 | 3. If people are discussing about the information needed in order to make a decision we might add information. 19 | 20 | # Context 21 | 22 | Use it during a process or design level EventStorming, when we need to be more explicit. -------------------------------------------------------------------------------- /_guiding-heuristics/eventstorming-let-every-pitch-for-hotspots-opportunities.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "EventStorming: Let everyone pitch there biggest constraint or opportunity" 3 | excerpt: "How can we lower political play and let everyone feel heard with dotvoting in a big picture EventStorming?" 4 | tags: guiding-heuristics eventstorming 5 | authors: Kenny Baas-Schwegler 6 | --- 7 | 8 | # Short description 9 | 10 | Just before dot voting for the theory of constraint in a big picture EventStorming, we want to let everyone speak up there mind. Do this with a two minutes elevator pitch were people in a monologue can pitch there biggest constraints or opportunities on the board. 11 | 12 | # Examples 13 | 14 | 1. Always do it before a dotvote in big picture EventStorming 15 | 2. When you notice there is more focus on specific hotspots or opportunities, we might want to use Deep Democracy instead of the pitch and dot voting. 16 | 17 | # Context 18 | 19 | During a big picture EventStorming we want to know what the groups feels the theory of constraint is. We want to make sure everything that needs to be said has been said. -------------------------------------------------------------------------------- /_guiding-heuristics/eventstorming-let-the-domain-expert-talk-and-the-rest-write-down-domain-events.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "EventStorming: Let the domain expert talk and the rest write down domain events" 3 | excerpt: "If only the domain experts has the knowledge, how can we transfer that knowledge the most effectivly and also challenge their assumption of the knowledge?" 4 | tags: guiding-heuristics eventstorming 5 | authors: Krisztina Hirth 6 | submitter: Kenny Baas-Schwegler 7 | --- 8 | 9 | # Description 10 | 11 | Let the domain expert tell the story and the rest of the group write down the domain events. 12 | 13 | # Summary of the solution 14 | 15 | When using EventStorming it can be that only one person has the domain knowledge, for instance when building a new product and there is no current process. Here chaotic exploration won't work. We want to let the other people maximise their knowledge gain by being active, and they can challange their own assumptions of that knowledge. 16 | -------------------------------------------------------------------------------- /_guiding-heuristics/eventstorming-make-a-ceremony-of-throwing-stickies-away.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "EventStorming: Make a ceremony of throwing things away" 3 | excerpt: "How do we make people comfortable with iterative modelling?" 4 | tags: guiding-heuristics eventstorming 5 | authors: Tobias Goeschel 6 | --- 7 | 8 | # Short description 9 | 10 | When people are new to EventStorming, their initial approach is often to be reluctant to write things that aren't 100% correct. By making an example of the first sticky you throw away as a facilitator, you allow everyone to try something, be wrong, and improve over time. Doing so helps set the stage for iterative learning. 11 | 12 | # Examples 13 | 14 | 1. Doing a Big Picture EventStorming. 15 | 2. Put a paper basket in the middle of the wall, so that it is easily accessible and very prominent. 16 | 17 | # Context 18 | 19 | Opening up a Big Picture EventStorming session 20 | -------------------------------------------------------------------------------- /_guiding-heuristics/eventstorming-one-facilitator-for-every-15-participants.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "EventStorming: One (co-)facilitator for every 15 participants" 3 | excerpt: "How many conversations can a single facilitator keep track of?" 4 | tags: guiding-heuristics eventstorming 5 | authors: Tobias Goeschel 6 | --- 7 | 8 | # Short description 9 | 10 | For a Big Picture EventStorming, we can have around 20-30+ people per wall - but even an experienced facilitator will have a hard time noticing subtleties, body language and tonal nuances when more than 2-3 conversations are going on at the same time. Limit the group size per facilitator to ~15. For larger groups, it is advisable to add co-facilitators to help with the things happening behind your back. 11 | 12 | # Examples 13 | 14 | 1. Doing a Big Picture EventStorming. 15 | 2. A co-facilitator should be present for every group of 15 participants. 16 | 3. The workshop agenda and general workings should be guided by the main facilitator. 17 | 18 | # Context 19 | 20 | Setting up for a Big Picture EventStorming session 21 | -------------------------------------------------------------------------------- /_guiding-heuristics/eventstorming-only-move-or-remove-stickies-when-discussed-with-the-writer.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "EventStorming: Only move or remove stickies when discussed with the writer" 3 | excerpt: "Who can move stickies around?" 4 | tags: guiding-heuristics eventstorming 5 | authors: Kenny Baas-Schwegler 6 | --- 7 | 8 | # Short description 9 | 10 | We can only move or remove stickies on the paper roll if the person had a discussion with the one who wrote it. Ask the group: Is it really the same concept as you think it is, what does the orginal writer actually mean? Is it the same Domain Event? 11 | 12 | # Examples 13 | 14 | 1. When you want to move an Domain Event stickie in orde to enforce the timeline 15 | 2. During Chaotic exploration we don't yet want to move stickies. 16 | 3. When all the stickies are already discussed, a lot has already been removed and the group in converting then everyone can (re)move stickies. 17 | 18 | # Context 19 | 20 | During an EventStorming after the chaotic exploration we want to enforce the timeline and start moving stuff around. It is very important that people don't take assumptions on the naming of other stickies they didn't write. We want to spark conversation and storming. So we want the group to know this. -------------------------------------------------------------------------------- /_guiding-heuristics/eventstorming-play-by-the-colour-coding-pattern.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "EventStorming: Play by the colour coding pattern" 3 | excerpt: "How do we introduce new colours during an EventStorming?" 4 | tags: guiding-heuristics eventstorming 5 | authors: Kenny Baas-Schwegler 6 | --- 7 | 8 | # Short description 9 | 10 | We can start a process or design EventStorming is two ways: 11 | 12 | 1. During an EventStorming session the group starts with a chaotic exploration of all the Domain Events. The next step is enforcing the timeline and create a consistent timeline. We continue until we completed the whole story line as a single flow, marking different cases with the hotspots. Since we explored enough we can now start playing by the colour coding rules, starting from the front and follow the colour pattern from the book. 13 | 2. Start with a starting Domain Event and mark an end Domain Event and work from there with the colour coding pattern. 14 | 15 | ![EventStorming colour coding pattern](/assets/images/eventstorming-colour-coding.jpg) 16 | 17 | # Examples 18 | 19 | 1. When there is not enough concepts popping up during enforcing the timeline, we can enforce more exploration and discussion by converting towards the colour coding pattern. 20 | 2. When the group is already experienced with EventStorming we can start straight away with the pattern. 21 | 3. When we explored the story in a previous EventStorming session we can start straight away with the pattern but with different starts and ending. 22 | 23 | # Context 24 | 25 | Use it during a process or design level EventStorming, when we need to be more explicit. -------------------------------------------------------------------------------- /_guiding-heuristics/eventstorming-remove-stickies-when-group-feels-sunk-cost.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "EventStorming: Lead by example and remove stickies as facilitator" 3 | excerpt: "Who removes stickies during an EventStorming?" 4 | tags: guiding-heuristics eventstorming 5 | authors: Kenny Baas-Schwegler 6 | --- 7 | 8 | # Short description 9 | 10 | A popular phrase in EventStorming is: You can see by the amount of stickies removed and crumbled on the grond how effective the EventStorming is. However sometimes a group is not removing stickies themselve. As a facilitator you want to lead by example and start removing stickies that can be removed. 11 | 12 | # Examples 13 | 14 | 1. When stickies are on top of each other and seems similar, ask the group which one they want to keep then throw the rest away. 15 | 2. When you notice the group cannot make a decision, or someone is not heard you got to dive into the why of the stickies first. 16 | 3. Sometimes stickies are not similar but sound similar. So make sure they are really the same! 17 | 18 | # Context 19 | 20 | During an EventStorming at any time from enforcing the timeline you can see ducplicated stickies. -------------------------------------------------------------------------------- /_guiding-heuristics/eventstorming-split-and-merge-above-7-people.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "EventStorming: Split and merge above 7 people on process and design level" 3 | excerpt: "How many people can we have during an EventStorming?" 4 | tags: guiding-heuristics eventstorming 5 | authors: Kenny Baas-Schwegler 6 | --- 7 | 8 | # Short description 9 | 10 | Have a maximum of 7 people for a process or a design leven EventStoming. We want to split and merge when we have more than 7 people. 11 | 12 | # Examples 13 | 14 | 1. Doing a process or design level EventStorming. 15 | 2. With a big picture EventStorming we never split and merge. 16 | 17 | # Context 18 | 19 | Setting up for a process or design level EventStorming. -------------------------------------------------------------------------------- /_guiding-heuristics/eventstorming-split-and-merge-during-converging-discussions.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "EventStorming: Split and merge during converging discussions" 3 | excerpt: "How do we visualise competing ideas during an EventStorming?" 4 | tags: guiding-heuristics eventstorming 5 | authors: Kenny Baas-Schwegler 6 | --- 7 | 8 | # Short description 9 | 10 | When there are competing ideas during an eventstorming, we want to visualise both ideas. Split both discussion, discuss and then merge. 11 | 12 | # Examples 13 | 14 | 1. When we are in the converging phase of eventstorming, we already moved a lot of ideas. Sometimes new ideas pop up. 15 | 2. When we are the chaotic exploration phase then we can just add the missing domain events. 16 | 17 | # Context 18 | 19 | Especially during a software design eventstorming, different ideas can pop up when we already started to use the colour coding. So people have the feeling that they want to leave there current ideas intact and not touch it. So then conversation start to move to invisible things. -------------------------------------------------------------------------------- /_guiding-heuristics/eventstorming-start-enforcing-the-timeline-when-everyone-added-their-domain-events.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "EventStorming: Start enforcing the timeline when everyone added their domain events" 3 | excerpt: "When do we start to structure the EventStorming by enforcing the timeline" 4 | tags: guiding-heuristics eventstorming 5 | authors: Kenny Baas-Schwegler 6 | --- 7 | 8 | # Short description 9 | 10 | During the start of an EventStorming we ask everyone in the group to write down their domain events they can think of. Then we ask them to stick these to the brownpaper in an ordered timeline. The timeline is what they have in their mind. Once everyone added their events will we start to structure and enforce the timeline. We want to postpone structuring as much as possible, because we can loose valuable insights. So once someone added their own events we need to wait on the rest. However people can start reading other people their events already and start discussing. 11 | 12 | # Examples 13 | 14 | 1. When someone is still writing domain events, make sure that they won't feel pressured by other people who already start to discuss. Give them time. 15 | 2. Once everyone added their events for now the facilitator can start introducing the enforcing the timeline step. 16 | 17 | # Context 18 | 19 | The biggest value from EventStorming is the storming part, and the first step is chaotic exploration. When we do a chaotic exploration first, instead of enforcing the colour coding pattern we need to wait until everyone added their domain events. -------------------------------------------------------------------------------- /_guiding-heuristics/eventstorming-switch-to-example-mapping-when-discussing-examples-of-a-rule.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "EventStorming: Switch to Example Mapping when discussing examples of business rules" 3 | excerpt: "When do we switch to example mapping from EventStorming?" 4 | tags: guiding-heuristics eventstorming example-mapping 5 | authors: Kenny Baas-Schwegler 6 | --- 7 | 8 | # Description 9 | 10 | During Process or Design level EventStorming we can get stuck in talking about invisible things for business constraint/rule like the purple or yellow sticky. It happens that we get into the use cases or examples discussion, it is here were we switch to Example Mapping. 11 | 12 | # Examples 13 | 14 | * Talking about consistent business constraints/rules (the yellow sticky) 15 | * Talking about translations use cases for a policy. 16 | 17 | # Summary of the solution 18 | 19 | EventStorming is really effective for telling stories in a timeline. It can be less effective when we start discussing use cases or examples that can all happen at one point in time. What can happen is that people move the discussion from the paper roll and stickies towards each other. Now we are discussing invisible things. 20 | -------------------------------------------------------------------------------- /_guiding-heuristics/eventstorming-use-as-is-process-modelling-when-exploring-a-green-field-problem-space.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "EventStorming: Use as-is process modelling when exploring a brown field problem space" 3 | excerpt: "When shall I use process modelling eventstorming for as-is discovery of my problem space?" 4 | tags: guiding-heuristics eventstorming 5 | authors: 6 | - Kenny Baas-Schwegler 7 | - Marco Heimeshoff 8 | - Paul Rayner 9 | --- 10 | 11 | # Description 12 | 13 | When working in a brownfield problem space, harvest current knowledge by exploring with as-is process modelling. 14 | 15 | # Summary of the solution 16 | 17 | When we start to explore the problem space in brown field we want to first know the current state the process and the software it uses now, before we can start changing the process and the software. Because a rewrite is dangerous for making the same mistakes, we will decouple and the current system and for that we need to harvest current knowledge. 18 | -------------------------------------------------------------------------------- /_guiding-heuristics/eventstorming-use-consistent-language-between-visual-collaboration-tools.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Use consistent language between visual collaboration tools" 3 | excerpt: "How can we refine and create an ubiquitous language?" 4 | tags: guiding-heuristics visual-collaboration eventstorming example-mapping 5 | authors: Kenny Baas-Schwegler 6 | --- 7 | 8 | # Description 9 | 10 | When combining several visual vollaboration tools, like EventStorming and Example Mapping, pay attention to the language. We want to be consistent in the language we use between the visual collaboration tools. For instance using ReserveSeats as an action/command in EventStroming, then we want to reuse it during Example Mapping saying when we reserve two seats. 11 | 12 | # Summary of the solution 13 | 14 | > To communicate effectively, the code must be based on the same language used to write the requirements—the same language that the developers speak with each other and with domain experts.” 15 | > ― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software 16 | 17 | Creating and making an ubiquitous language consistent is one of the hardest part of designing good software. It is however also one of the important things to do when building complex software. Language is always in flux, so it is really important to constantly try to keep it consistent. -------------------------------------------------------------------------------- /_guiding-heuristics/eventstorming-use-standing-tables.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "EventStorming: Use standing table" 3 | excerpt: "The no-table rule has an exception" 4 | tags: guiding-heuristics eventstorming 5 | authors: Cédric Pontet 6 | --- 7 | 8 | # Description 9 | 10 | Alberto Brandolini often says that meeting room tables and chairs should be removed or pushed away when preparing an EventStorming workshop. This is the best way to foster collaboration, engagement, and mobility of your participants. However, where do you put all the sticky notes and markers when you don't have a table? 11 | 12 | # Summary of the solution 13 | 14 | Using standing tables for stationery is a great way to avoid clutter on the floor or having your supplies dispatched everywhere in the room. They allow people to use them to write down stickies, without getting in the way by forcing them to sit down, since writing down a sticky note on your lap may not be the best for readability. 15 | 16 | Standing tables are easy to move around and can be put close to the action, without impairing collaboration. You may want to use several of them, depending on the number of people you have in your meeting. But make sure not to have too many in the room, which would reduce mobility and damage collaboration. Usually, one standing table for eight people in the group is a good rule of thumb. 17 | -------------------------------------------------------------------------------- /_guiding-heuristics/eventstorming-use-to-be-process-modelling-when-exploring-a-brown-field-problem-space.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "EventStorming: Use to-be process modelling when exploring a green field problem space" 3 | excerpt: "When shall I use process modelling eventstorming for to-be discovery of my problem space?" 4 | tags: guiding-heuristics eventstorming 5 | authors: 6 | - Kenny Baas-Schwegler 7 | - Marco Heimeshoff 8 | - Paul Rayner 9 | --- 10 | 11 | # Short description 12 | 13 | When working in a greenfield problem space, start by exploring with to-be process modelling. 14 | 15 | # Summary of the solution 16 | 17 | When we start to explore the problem space with eventstorming in a green field there is no current process to explore. In this case we want to do eventstorming for the to-be situation. However we don't want to jump into design, so we do a process eventstorming on the to-be situation. -------------------------------------------------------------------------------- /_guiding-heuristics/eventstorming-when-there-is-a-story-to-tell-start-with-eventstorming.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "EventStorming: When there is a story to tell, start with EventStorming" 3 | excerpt: "When should I use EventStorming?" 4 | tags: guiding-heuristics eventstorming 5 | authors: Kenny Baas-Schwegler 6 | --- 7 | 8 | # Description 9 | 10 | When there is a story to tell, for instance a business process or a customer journey or even doing a planning session, then start your visual collaboration with EventStorming. 11 | 12 | # Examples 13 | 14 | 1. Designing for a new product with customer journey and business process 15 | 2. Discussing the complete flow of the business in a big picture 16 | 3. Exploring the current business process between teams 17 | 4. Setting up a planning 18 | 19 | # Summary of the solution 20 | 21 | EventStorming is a collaborative modelling tool, and with every tool it is not a silver bullet. So the question is, when should I use EventStorming? -------------------------------------------------------------------------------- /_guiding-heuristics/everyone-can-write-gherkin.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Everyone can write Gherking script" 3 | excerpt: "Who writes Gherkin scripts?" 4 | tags: guiding-heuristics behaviour-driven-development 5 | authors: Kenny Baas-Schwegler 6 | --- 7 | 8 | # Short description 9 | 10 | Everyone should formalise examples when using the Gherkin language. Then you share it back with the team before you pull the story in the sprint as a last check that everyone is aligned 11 | 12 | # Context 13 | 14 | When doing Behaviour-Driven Development we want to formalise our examples so we can possibly use these to automate them. -------------------------------------------------------------------------------- /_guiding-heuristics/example-mapping-prepare-visualisations-upfront.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Example Mapping: Prepare visualisations upfront" 3 | excerpt: "How can we make a session with complex examples more efficient?" 4 | tags: guiding-heuristics example-mapping behaviour-driven-development remote-example-mapping 5 | authors: 6 | - Kenny Baas-Schwegler 7 | - Nick Tune 8 | --- 9 | 10 | # Short description 11 | 12 | When story will get complex visualisation, we are more busy with finding the right visualisation for them. Prepare these visualisations up front so that the conversation will be about the examples rather on how to visualise. 13 | 14 | # Context 15 | 16 | When doing Behaviour-Driven Development we want to discover more knowledge and we can do that by using Example Mapping. During example mapping we start writing our examples for a specific business rule. We want to visualise these examples especially complex ones. -------------------------------------------------------------------------------- /_guiding-heuristics/example-mapping-split-business-rule-above-3-examples.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Example Mapping: Split business rule above three examples" 3 | excerpt: "When can we discover more business rules during example mapping?" 4 | tags: guiding-heuristics example-mapping behaviour-driven-development 5 | authors: Kenny Baas-Schwegler 6 | --- 7 | 8 | # Short description 9 | 10 | When a rule get's more than three example, split up the rule into two seperate rules. 11 | 12 | # Context 13 | 14 | When doing Behaviour-Driven Development we want to discover more knowledge and we can do that by using Example Mapping. During example mapping we start writing our examples for a specific business rule. -------------------------------------------------------------------------------- /_guiding-heuristics/example-mapping-split-business-rule-when-an-example-has-more-than-one-check.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Example Mapping: Split business rule when an example has more than one check" 3 | excerpt: "When can we discover more business rules during example mapping?" 4 | tags: guiding-heuristics example-mapping behaviour-driven-development 5 | authors: Kenny Baas-Schwegler 6 | --- 7 | 8 | # Short description 9 | 10 | When and example needs to check multiple states, it split up the business rule. 11 | 12 | # Context 13 | 14 | When doing Behaviour-Driven Development we want to discover more knowledge and we can do that by using Example Mapping. During example mapping we start writing our examples for a specific business rule. -------------------------------------------------------------------------------- /_guiding-heuristics/example-mapping-split-the-story-on-business-rules.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Example Mapping: Split the story on business rules" 3 | excerpt: "How can we split a story up?" 4 | tags: guiding-heuristics example-mapping behaviour-driven-development 5 | authors: Kenny Baas-Schwegler 6 | --- 7 | 8 | # Short description 9 | 10 | After you run an Example Map, you can split up that story based on the rules that are clear and can be already implemented. Splitting it up makes the story smaller and increases faster feedback. 11 | 12 | # Context 13 | 14 | When doing Behaviour-Driven Development we want to discover more knowledge and we can do that by using Example Mapping. During example mapping we start writing our examples for a specific business rule. -------------------------------------------------------------------------------- /_guiding-heuristics/example-mapping-use-a-maximum-of-20-minutes-for-a-story.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Example Mapping: Use a maximum of 20 minutes for a story" 3 | excerpt: "How long does Example Mapping take?" 4 | tags: guiding-heuristics example-mapping behaviour-driven-development 5 | authors: Kenny Baas-Schwegler 6 | --- 7 | 8 | # Short description 9 | 10 | When Example Mapping a story we want to timebox our Example Mapping for it to 20 minutes. After we want to either split the story or answer the questions before pulling it out again. 11 | 12 | # Context 13 | 14 | When doing Behaviour-Driven Development we want to discover more knowledge and we can do that by using Example Mapping. During example mapping we start writing our examples for a specific business rule. -------------------------------------------------------------------------------- /_guiding-heuristics/example-mapping-visualise-examples.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Example Mapping: Visualise Examples" 3 | excerpt: "How can we create a better shared understanding about the examples?" 4 | tags: guiding-heuristics example-mapping behaviour-driven-development 5 | authors: Kenny Baas-Schwegler 6 | --- 7 | 8 | # Short description 9 | 10 | When possible, make a visualisation explaining your concrete scenario for a business rule. 11 | 12 | # Context 13 | 14 | When doing Behaviour-Driven Development we want to discover more knowledge and we can do that by using Example Mapping. During example mapping we start writing our examples for a specific business rule. When we for instance create scenario's for a theather or cinema allocation system, make a visualisation of the seating arrangement for the example that relate to allocating seats. -------------------------------------------------------------------------------- /_guiding-heuristics/example-mapping-write-down-any-future-wishes-on-a-red-sticky.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Example Mapping: Write down any future wishes on a red sticky" 3 | excerpt: "How can we pick the better fit model to accomodate for future wishes?" 4 | tags: guiding-heuristics example-mapping behaviour-driven-development 5 | authors: Kenny Baas-Schwegler 6 | --- 7 | 8 | # Short description 9 | 10 | A lot times during example mapping assumptions and questions pop up which get written on a red sticky. Use the red sticky also to put down any future wishes the business might have. It can be helpfull when designing your model and choosing the one that can accomodate to that future wish. We don't want to accomodate for it now however. 11 | 12 | # Context 13 | 14 | When doing Behaviour-Driven Development we want to discover more knowledge and we can do that by using Example Mapping. During example mapping we start writing our examples for a specific business rule. -------------------------------------------------------------------------------- /_guiding-heuristics/example-mapping-write-down-domain-concepts-on-a-white-sticky.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Example Mapping: Write down domain concepts on a white sticky" 3 | excerpt: "How can Example Mapping help design better models?" 4 | tags: guiding-heuristics example-mapping behaviour-driven-development 5 | authors: Kenny Baas-Schwegler 6 | --- 7 | 8 | # Short description 9 | 10 | During Example Mapping a lot of domain concepts pop up. For instance definitions like what do you mean with a row for a cinema reservation system. Write these domain concepts on a white sticky so that it helps up in modelling our software. 11 | 12 | # Context 13 | 14 | When doing Behaviour-Driven Development we want to discover more knowledge and we can do that by using Example Mapping. During example mapping we start writing our examples for a specific business rule. -------------------------------------------------------------------------------- /_guiding-heuristics/example-mapping-write-examples-as-intentions-over-implementation.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Example Mapping: Write examples and formalise as intentions over implementation" 3 | excerpt: "How can we remove the constraints of the current systen?" 4 | tags: guiding-heuristics example-mapping behaviour-driven-development 5 | authors: Kenny Baas-Schwegler 6 | --- 7 | 8 | # Short description 9 | 10 | When coming up with examples we want to let go of how the sytem is working now, and write down the intention as behaviour. For instance an implementation is: 11 | 12 | ``` 13 | Given no seats are reserved 14 | When the user clicks on the reserve tickets button 15 | Then the user should see the following seats reverved 16 | ``` 17 | 18 | instead we want: 19 | 20 | ``` 21 | Given no seats are reserved 22 | When we want to allocate seats 23 | Then seats a9 - a11 will be reserved 24 | ``` 25 | 26 | At this stage I am not interested at all how we can automate it yet. Just that the example is clear. 27 | 28 | 29 | # Context 30 | 31 | When doing Behaviour-Driven Development we want to discover more knowledge and we can do that by using Example Mapping. During example mapping we start writing our examples for a specific business rule. A lot of examples explain the implementation of the system. For instance when a user clicks on button then. It can lead to all sort of coupling and being locked into the old system. -------------------------------------------------------------------------------- /_guiding-heuristics/explore-language-change-language-to-change-how-people-think.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Explore language: change language on purpose to change how people think" 3 | excerpt: "How can we battle confirmation bias while designing and modelling?" 4 | tags: guiding-heuristics eventstorming collaborative-modelling 5 | authors: Kenny Baas-Schwegler 6 | --- 7 | 8 | # Short description 9 | 10 | Everyone can fall easily into the trap of the confirmation bias. You perceive a word in your own way and it is hard to get out of that way of thinking. In order to help people move out of there confirmation bias, change the language they use while designing and modelling in order to get different insights. 11 | 12 | > “It is impossible for a person to learn what he thinks they already knows.” 13 | > 14 | > -Epictetus, Discourses, Book II, ch. 17 15 | 16 | # Examples 17 | 18 | 1. During a collaborate modelling session and proposing a model, explore language while still discovering the language, try and change that. 19 | 2. While converging and formalising a model just before you can code probe, refine the language and don't change language on purpose. 20 | 21 | # Context 22 | 23 | While collaborativly model and design new products or requirements for a product we are left with past learnings. -------------------------------------------------------------------------------- /_guiding-heuristics/let-someone-from-another-team-facilitate-your-teams-collaborative-modelling-session.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Let someone from another team facilitate your collaborative modelling session" 3 | excerpt: "How can we make sure everything that has to be said during a collaborative modelling session?" 4 | tags: guiding-heuristics collaborative-modelling 5 | authors: Kenny Baas-Schwegler 6 | --- 7 | 8 | # Short description 9 | 10 | Even with a team that is used to each other, there will be some biased towards each others insights. When someone from the team start facilitating a collaborative modelling session, this person won't be neutral. If we really want to get all the insights we need to make more effective product, we need a more neutral facilitator. While getting some external costs extra money, we might be able to find someone from another team willing to do do it. Althought that persona can also be biased, it is easier to be neutral for someone from outside the team. 11 | 12 | # Summary of the solution 13 | 14 | If we want to model the most effectivly, we need to gain all information and knowledge available that there is. However that sounds easier than it is. Ranking and bias might opress certain perceptions, especially in a group that seems aligned. -------------------------------------------------------------------------------- /_guiding-heuristics/remote-eventstorming-break-out-groups-between-pivotal-events.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Remote EventStorming: Break-out groups between pivotal events" 3 | excerpt: "How we we start enforcing the timeline in a remote big picture eventstorming with over 10 people?" 4 | tags: guiding-heuristics eventstorming remote-eventstorming remote-workshop 5 | authors: Kenny Baas-Schwegler 6 | --- 7 | 8 | # Description 9 | 10 | If we get more than 10 people during enforcing the timeline with a remote big picture eventstorming, the effectiveness and amount of insights goes down. The sweetspot here seem to be around 4-8 people in one virtual meeting room doing an enforcing the timeline. This poses a challange, as we want to model the entire business domain on one board with big picture eventstorming. During a physical events, people will usually split into several boards, cleaning it up. But how do we split up during a remote session, were people cannot just walk around? 11 | 12 | # Summary of the solution 13 | 14 | Decide together on pivotal events, or emerging pivotal events. Let the group move their own stickies in between these pivotal events. Now create break-out groups and split the group up between the pivotal events. Let people at the start self-organise, but be carefull that some break-out groups do not fill up. Iterate back to the main room every 15-20 minutes for a recap and realignment. Eventually always finish with a walktrough narrative. 15 | 16 | ![Emerging pivotal events](/assets/images/remote-eventstorming-bp-break-out.png) 17 | 18 | -------------------------------------------------------------------------------- /_guiding-heuristics/remote-eventstorming-do-breaks-after-10-20-min-of-work.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Remote EventStorming: Do breaks after segments of 10-20 min of work" 3 | excerpt: "How do we keep people engaged?" 4 | tags: guiding-heuristics EventStorming remote-eventstorming remote-workshop 5 | authors: Kenny Baas-Schwegler 6 | --- 7 | 8 | # Description 9 | 10 | Brain science shows us that shorter trumps longer. Especially for a remote EventStorming we need to keep people engaged as much as possible. So create segments of 10-20 minutus during your EventStorming, and take breaks in between. 11 | 12 | # Summary of the solution 13 | 14 | The human brain learns best when content is divided into smaller “chunks” or segments of information. Patricia Wolfe illustrates this principle with the example of phone numbers. “Phone numbers are not remembered as a list of ten numbers but as two chunks of three numbers and one chunk of four”. Grouping facts into larger categories or major concepts is another way of chunking. So is dividing content-delivery into shorter segments of time—about ten or twenty minutes, rather than sixty or ninety minutes. John Medina describes this process thus: “The way to make long-term memory more reliable is to incorporate new information gradually and repeat it in timed intervals. 15 | 16 | # resource 17 | 18 | https://bowperson.com/wp-content/uploads/2014/11/SixTrumpsArticle220101.pdf -------------------------------------------------------------------------------- /_guiding-heuristics/remote-eventstorming-everyone-has-their-camera-on.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Remote EventStorming: Everyone has their camera on with split screens" 3 | excerpt: "How do we create a safe remote environment?" 4 | tags: guiding-heuristics remote-eventstorming remote-workshop 5 | authors: Kenny Baas-Schwegler 6 | --- 7 | 8 | # Description 9 | 10 | Everyone should have their camera on and uses two screens. On one screen we can look each other in the eyes and on the other one we use the remote tool. 11 | 12 | # Summary of the solution 13 | 14 | During our remote EventStorming on the virtual Domain-driven design meetup, we observed that while enforcing the timeline engagement was low. During offline EventStorming it can happen as well, but an excellent facilitator will start asking questions. The problem is, using tools like miro you cannot see where people are working on, so it is hard to know what is going on. 15 | -------------------------------------------------------------------------------- /_guiding-heuristics/remote-eventstorming-have-a-dedicated-facilitator.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Remote EventStorming: have a dedicated facilitator" 3 | excerpt: "How do we create a safe remote environment?" 4 | tags: guiding-heuristics remote-eventstorming remote-workshop 5 | authors: Kenny Baas-Schwegler 6 | --- 7 | 8 | # Description 9 | 10 | We need to have a dedicated facilitator, someone who does makes it a safe for everyone say the things that need to be said – even ideas that at first glance appear controversial, wrong, or at odds with their own beliefs. The facilitator must focus on seeing everyone trough their camera at all times. With the power of reflective listening, they can create compassion and show neutrality to the group. 11 | 12 | > The only justification for our concepts and systems of concepts is that they serve to represent the complex of our experiences; beyond this they have not legitimacy. 13 | > - Albert Einstein 14 | 15 | # Summary of the solution 16 | 17 | EventStorming facilitates in creating a pool of shared meaning. Groups and teams must have a pool of shared meaning to generate better decisions and have more valuable insights. Writing and sharing your Domain Events seems easy, but does everyone in the team feel safe enough to put say what needs to be said? Offline it is also much easier for a facilitator to use their meta-skills of super listening (hear, see, and feel the energy) than in an online setting. 18 | -------------------------------------------------------------------------------- /_guiding-heuristics/remote-eventstorming-let participants move in breaks.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Remote EventStorming: Let participants move in breaks" 3 | excerpt: "How do we keep people engaged?" 4 | tags: guiding-heuristics remote-eventstorming remote-workshop 5 | authors: Kenny Baas-Schwegler 6 | --- 7 | 8 | # Description 9 | 10 | Brain science shows us that movement trumps sitting. Meaning with remote EventStorming we ask the participants to do some movement during breaks. 11 | 12 | # Summary of the solution 13 | 14 | Sitting for extended lengths of time makes thinking and learning more difficult to do because the oxygen levels in the body decrease. Remote EventStorming is different from EventStorming because offline we keep moving. 15 | 16 | # resource 17 | 18 | https://bowperson.com/wp-content/uploads/2014/11/SixTrumpsArticle220101.pdf -------------------------------------------------------------------------------- /_guiding-heuristics/remote-eventstorming-run-for-a-maximum-of-two-hours-in-a-day.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Remote EventStorming: Run for a maximum of two hours in a day" 3 | excerpt: "How long should a remote EventStorming last?" 4 | tags: guiding-heuristics remote-eventstorming remote-workshop 5 | authors: Kenny Baas-Schwegler 6 | --- 7 | 8 | # Description 9 | 10 | Keep EventStorming sessions which are remote up to a maximum of two hours for a day 11 | 12 | # Summary of the solution 13 | 14 | Sitting for extended lengths of time makes thinking and learning more difficult to do because the oxygen levels in the body decrease. During an offline EventStorming, we always tell the importance of oxygen. Doing remote work, we often lack that fresh air, we don’t move enough, and that resolves that we cannot stay focused for an extended period, even with short movement breaks in between. 15 | 16 | # resource 17 | 18 | https://bowperson.com/wp-content/uploads/2014/11/SixTrumpsArticle220101.pdf -------------------------------------------------------------------------------- /_guiding-heuristics/remote-eventstorming-switch-driver-every-5-minutes-during-enforcing-the-timeline.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Remote EventStorming: Switch driver every 5 minutes during enforcing the timeline" 3 | excerpt: "How do we keep the interaction going in a remote EventStorming?" 4 | tags: guiding-heuristics remote-eventstorming remote-workshop 5 | authors: Kenny Baas-Schwegler 6 | --- 7 | 8 | # Description 9 | 10 | When we enforce the timeline we want to have a dedicated person (the driver) moving stickies on the board and make sure that information sticks. Sharon Bowman can help us here in these following trumps: 11 | 12 | * Shorter trumps longer 13 | * Different trumps same. 14 | * Talking trumps listening 15 | 16 | So switch the driver every 5 min naturally to the next person, so that each person will experience these trumps. 17 | 18 | # Summary of the solution 19 | 20 | EventStorming facilitates in creating a pool of shared meaning by creating conversation about each other perception. Physicly the moment people interact on a board it comes natural, however in a remote setting we need to change the way we do that. 21 | -------------------------------------------------------------------------------- /_guiding-heuristics/remote-eventstorming-use-a-mobprogramming-style-enforcing-the-timeline.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Remote EventStorming: Use a mob programming style enforcing the timeline" 3 | excerpt: "How do we engage people during a remote EventStorming?" 4 | tags: guiding-heuristics remote-eventstorming remote-work 5 | authors: Kenny Baas-Schwegler 6 | --- 7 | 8 | # Description 9 | 10 | Start enforcing a single flow EventStorm, have only one person able to edit post-its and have the rest navigate that person. 11 | 12 | 13 | # Summary of the solution 14 | 15 | During our remote EventStorming on the virtual Domain-driven design meetup, we observed that while enforcing the timeline engagement was low. During offline EventStorming it can happen as well, but an excellent facilitator will start asking questions. The problem is, using tools like miro you cannot see where people are working on, so it is hard to know what is going on. 16 | -------------------------------------------------------------------------------- /_guiding-heuristics/start-a-workshop-with-a-checkin.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Start a workshop with a check-in" 3 | excerpt: "How can we start a workshop so that people are present, feel safe and can say what needs to be said?" 4 | tags: guiding-heuristics eventstorming workshops collaborative-modelling remote-eventstorming remote-workshop 5 | authors: Pim Smeets 6 | --- 7 | 8 | # Short description 9 | 10 | Start every workshop by doing a check-in. We ask context-relevant questions that allow everyone to 'touch ground' on how they are doing and to share anything that might be relevant in the context of the session with the group. Typically this is also an opportunity to share your expectations of the session itself. Check-ins are done monologue- and popcorn-style. The facilitator writes 2-3 questions on a whiteboard and everyone in the group can choose to speak when they feel comfortable. 11 | 12 | # Summary of the solution 13 | 14 | Someone may have had a bad night of sleep, a sick child at home or a wisdom tooth that is acting up. Personal matters will affect your behaviour during a workshop. If you don't have an opportunity to explain to others how you 'feel' beforehand, you may be perceived as uninterested or otherwise obstructing the progress. 15 | -------------------------------------------------------------------------------- /_guiding-heuristics/stories-starting-with-todos-are-smell.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Stories Starting With ToDos Are a Smell" 3 | excerpt: "Stories starting with ToDos are a smell for focusing on the \"how\" and not on the \"why\"" 4 | tags: guiding-heuristics behaviour-driven-development ubiquitous-language 5 | authors: Krisztina Hirth 6 | submitter: Krisztina Hirth 7 | --- 8 | 9 | # Short description 10 | 11 | Stories, requests beginning with "to do" must be reformulated so that they describe the benefits and the users of those benefits. 12 | Otherwise they move the focus from the "why" to the "how" and drives the discussion to the technical implementation instead of the domain behaviour. 13 | # Context 14 | 15 | Implementing DDD needs a shared knowledge about the domain and the common effort to dive deeper and deeper when this understanding grows. This means, the team should focus on the domain and not on the technical details. 16 | -------------------------------------------------------------------------------- /_includes/documents-collection.html: -------------------------------------------------------------------------------- 1 | 2 | {% assign entries = site[include.collection] %} 3 | 4 | {% if include.sort_by == 'title' %} 5 | {% if include.sort_order == 'reverse' %} 6 | {% assign entries = entries | sort: 'title' | reverse %} 7 | {% else %} 8 | {% assign entries = entries | sort: 'title' %} 9 | {% endif %} 10 | {% elsif include.sort_by == 'date' %} 11 | {% if include.sort_order == 'reverse' %} 12 | {% assign entries = entries | sort: 'date' | reverse %} 13 | {% else %} 14 | {% assign entries = entries | sort: 'date' %} 15 | {% endif %} 16 | {% endif %} 17 | 18 | {%- if page.tag -%} 19 | {%- for post in entries -%} 20 | {% if post.tags contains page.tag %} 21 | {% include archive-single.html %} 22 | {% endif %} 23 | {%- endfor -%} 24 | {%- else -%} 25 | {%- for post in entries -%} 26 | {% include archive-single.html %} 27 | {%- endfor -%} 28 | {%- endif -%} -------------------------------------------------------------------------------- /_layouts/heuristics.html: -------------------------------------------------------------------------------- 1 | --- 2 | layout: single 3 | --- 4 | 5 | {% if page.authors.first %} 6 | Authors: 7 | {% assign last_author = page.authors | last %} 8 | {% for author in page.authors %} 9 | {{ author }} 10 | {%- if author != last_author -%} 11 | , 12 | {%- endif -%} 13 | {% endfor %} 14 | {% else %} 15 | Author: 16 | {{page.authors}} 17 | {% endif %} 18 | 19 | {% if page.submitter %}
Submitter: {{page.submitter}} {% endif %} 20 |
21 | 22 | {% for tag in page.tags %} 23 | {{ tag }} 24 | {% endfor %} 25 | 26 |

27 | 28 | {{ content }} -------------------------------------------------------------------------------- /_pages/align-with-business-value.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Align with business value" 3 | excerpt: "" 4 | layout: collection 5 | permalink: /align-with-business-value/ 6 | collection: design-heuristics 7 | entries_layout: list 8 | tag: align-with-business-value 9 | sidebar: 10 | nav: "heuristics" 11 | --- 12 | 13 | # Short description 14 | 15 | We should align boundaries in sociotechnical systems to optimise Return of Investment. 16 | 17 | # Context 18 | 19 | Use these at a strategic level when defining bounded context. When you want to seperate core domains from supporting and generic subdomains 20 | 21 | 22 | -------------------------------------------------------------------------------- /_pages/behaviour-driven-development.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Behaviour-Driven Development Guiding Heuristics" 3 | excerpt: "" 4 | layout: collection 5 | permalink: /behaviour-driven-development/ 6 | collection: guiding-heuristics 7 | entries_layout: list 8 | tag: behaviour-driven-development 9 | sidebar: 10 | nav: "heuristics" 11 | --- 12 | -------------------------------------------------------------------------------- /_pages/design-heuristics.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Design Heuristics 3 | excerpt: "Heuristics we use to solve a specific problem" 4 | layout: collection 5 | permalink: /design-heuristics/ 6 | collection: design-heuristics 7 | entries_layout: list 8 | sidebar: 9 | nav: "heuristics" 10 | --- -------------------------------------------------------------------------------- /_pages/eventstorming.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "EventStorming Guiding Heuristics" 3 | excerpt: "" 4 | layout: collection 5 | permalink: /eventstorming/ 6 | collection: guiding-heuristics 7 | entries_layout: list 8 | tag: eventstorming 9 | sidebar: 10 | nav: "heuristics" 11 | --- 12 | -------------------------------------------------------------------------------- /_pages/example-mapping.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Example Mapping Guiding Heuristics" 3 | excerpt: "" 4 | layout: collection 5 | permalink: /example-mapping/ 6 | collection: guiding-heuristics 7 | entries_layout: list 8 | tag: example-mapping 9 | sidebar: 10 | nav: "heuristics" 11 | --- 12 | -------------------------------------------------------------------------------- /_pages/guiding-heuristics.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Guiding Heuristics 3 | excerpt: "Heuristics that guide our use of other heuristics (meta-heuristics, if you will)" 4 | layout: collection 5 | permalink: /guiding-heuristics/ 6 | collection: guiding-heuristics 7 | entries_layout: list 8 | sidebar: 9 | nav: "heuristics" 10 | --- -------------------------------------------------------------------------------- /_pages/heuristics.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Heuristics 3 | layout: category 4 | permalink: /heuristics/ 5 | sidebar: 6 | nav: "heuristics" 7 | --- 8 | 9 | > 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. 10 | > 11 | > -Billy Vaughn Koen 12 | 13 | Billy describes three different type of heuristics: 14 | 15 | 1. Heuristics we use to solve a specific problem; 16 | 2. Heuristics that guide our use of other heuristics (meta-heuristics, if you will); 17 | 3. Heuristics that determine our attitude and behavior towards design or the world and the way we work. 18 | 19 | On this site you will find these three different heuristics as collections under: 20 | * [Design](./../design-heuristics/) 21 | * [Guiding](./../guiding-heuristics/) 22 | * [Value-based heuristics](./../value-based-heuristics/) -------------------------------------------------------------------------------- /_pages/remote-eventstorming.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "EventStorming Guiding Heuristics" 3 | excerpt: "" 4 | layout: collection 5 | permalink: /remote-eventstorming/ 6 | collection: guiding-heuristics 7 | entries_layout: list 8 | tag: remote-eventstorming 9 | sidebar: 10 | nav: "heuristics" 11 | --- 12 | -------------------------------------------------------------------------------- /_pages/submit.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: About this website 3 | layout: splash 4 | permalink: /submit/ 5 | header: 6 | overlay_color: "#000" 7 | overlay_filter: "0.5" 8 | overlay_image: /assets/images/kandinsky.jpg 9 | --- 10 | 11 | # How it works 12 | 13 | This sites works with jekyll trough a github repo linked with netlify. You can fork the github repo [here](https://github.com/Baasie/domain-driven-design-heuristics) and create a pull request of your own heuristics. 14 | 15 | To work with Jekyll check out the [Jekyll Site](https://jekyllrb.com/) 16 | 17 | # Adding your own heuristics 18 | 19 | You can add your own heuristics as a markdown file under the respective _XXXX-heuristics directory. 20 | 21 | Not everyone uses github so alterntivly you can send your heuristic in an email to submit@dddheuristic.com. 22 | 23 | # Writing, Remembering, and Sharing Design Heuristics 24 | 25 | For more information please read about how to write Heuristics Rebecca her article [Writing, Remembering, and Sharing Design Heuristics](http://wirfs-brock.com/blog/2019/04/12/writing/) 26 | 27 | There are some contraint when submitting a heuristic, you need to use at least the follow template: 28 | 29 | ## Template 30 | 31 | ``` markdown 32 | --- 33 | title: {The title of the heuristic} 34 | excerpt: {Summary of Problem or the question that the heuristic solves} 35 | tags: {tags seperated by space, fill in what you think is best} 36 | authors: {the authors as a yaml list} 37 | submitter: {The submitter} (optional) 38 | --- 39 | 40 | Example: 41 | 42 | --- 43 | title: "Heuristic" 44 | excerpt: "When I am faced with a problem, what do I do?" 45 | tags: Aggregate Bounded-Context socio-technical-systems 46 | authors: 47 | - Cindy 48 | - John 49 | --- 50 | 51 | or 52 | 53 | --- 54 | title: "Heuristic" 55 | excerpt: "When I am faced with a problem, what do I do?" 56 | tags: Aggregate Bounded-Context socio-technical-systems 57 | authors: Cindy 58 | submitter: Gert 59 | --- 60 | 61 | ``` 62 | 63 | You can fill in the rest the way you like it, but here are two examples from Rebecca her article 64 | 65 | ### Quick Heuristic from QHE cards 66 | 67 | ``` markdown 68 | --- 69 | title: {The title of the heuristic} 70 | excerpt: {Summary of Problem or the question that the heuristic solves} 71 | tags: {tags seperated by space, fill in what you think is best} 72 | authors: {the authors as a yaml list} 73 | submitter: {The submitter} (optional) 74 | --- 75 | 76 | # Short description 77 | A short description of the heuristics 78 | 79 | # Examples 80 | Give some examples 81 | 82 | ``` 83 | 84 | ### From QHE card to a Heuristic gist: 85 | 86 | ``` markdown 87 | --- 88 | title: {The title of the heuristic} 89 | excerpt: {Summary of Problem or the question that the heuristic solves} 90 | tags: {tags seperated by space, fill in what you think is best} 91 | authors: {the authors as a yaml list} 92 | submitter: {The submitter} (optional) 93 | --- 94 | 95 | # Description 96 | A description of the heuristics 97 | 98 | # Summary of Solution 99 | The solution of the heuristic 100 | 101 | ``` 102 | 103 | # Contribute 104 | 105 | Any help is welcome and needed, if you have any feedback please feel free to either create pull requests or tickets or send us an email! 106 | -------------------------------------------------------------------------------- /_pages/value-based-heuristics.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Value-based Heuristics 3 | excerpt: "Heuristics that determine our attitude and behavior towards design or the world and the way we work" 4 | layout: collection 5 | permalink: /value-based-heuristics/ 6 | collection: value-based-heuristics 7 | entries_layout: list 8 | sidebar: 9 | nav: "heuristics" 10 | --- -------------------------------------------------------------------------------- /_value-based-heuristics/deep-democracy-everyone-is-right-no-one-has-the-monopoly-to-the-truth.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Deep Democracy: Everyone is right, no one has the monopoly to the truth" 3 | excerpt: "" 4 | tags: value-based-heuristics deep-democracy 5 | authors: Kenny Baas-Schwegler 6 | --- 7 | 8 | # Description 9 | 10 | We live in a Deep Democratic world, where nothing has meaning of itself. When we design collaborativly we all have our own model of the world. We want to use all these different angles and perceptions of people when mdesigning to get the best possible model. That is why our attitude toward each other shuld be that everyone is right, and no one has the monopoly to the truth. Using that behaviour will get us in a state of curiousity towards others perception, and we will continuously learn from each other. 11 | -------------------------------------------------------------------------------- /assets/images/blank-avatar.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Virtual-Domain-driven-design/domain-driven-design-heuristics/361785492c5afea2e1e912b061cc78ce82f7070b/assets/images/blank-avatar.png -------------------------------------------------------------------------------- /assets/images/bounded-context.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Virtual-Domain-driven-design/domain-driven-design-heuristics/361785492c5afea2e1e912b061cc78ce82f7070b/assets/images/bounded-context.png -------------------------------------------------------------------------------- /assets/images/emerging-pivotal-events.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Virtual-Domain-driven-design/domain-driven-design-heuristics/361785492c5afea2e1e912b061cc78ce82f7070b/assets/images/emerging-pivotal-events.png -------------------------------------------------------------------------------- /assets/images/eventstorming-colour-coding.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Virtual-Domain-driven-design/domain-driven-design-heuristics/361785492c5afea2e1e912b061cc78ce82f7070b/assets/images/eventstorming-colour-coding.jpg -------------------------------------------------------------------------------- /assets/images/kandinsky.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Virtual-Domain-driven-design/domain-driven-design-heuristics/361785492c5afea2e1e912b061cc78ce82f7070b/assets/images/kandinsky.jpg -------------------------------------------------------------------------------- /assets/images/remote-eventstorming-bp-break-out.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Virtual-Domain-driven-design/domain-driven-design-heuristics/361785492c5afea2e1e912b061cc78ce82f7070b/assets/images/remote-eventstorming-bp-break-out.png -------------------------------------------------------------------------------- /assets/images/value-stream-contexts.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Virtual-Domain-driven-design/domain-driven-design-heuristics/361785492c5afea2e1e912b061cc78ce82f7070b/assets/images/value-stream-contexts.png -------------------------------------------------------------------------------- /assets/images/value-stream-events.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Virtual-Domain-driven-design/domain-driven-design-heuristics/361785492c5afea2e1e912b061cc78ce82f7070b/assets/images/value-stream-events.png -------------------------------------------------------------------------------- /assets/images/value-stream.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Virtual-Domain-driven-design/domain-driven-design-heuristics/361785492c5afea2e1e912b061cc78ce82f7070b/assets/images/value-stream.png -------------------------------------------------------------------------------- /assets/images/vddd_logo_small.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Virtual-Domain-driven-design/domain-driven-design-heuristics/361785492c5afea2e1e912b061cc78ce82f7070b/assets/images/vddd_logo_small.png -------------------------------------------------------------------------------- /index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Domain-Driven Design Heuristics 3 | excerpt: "Heuristics to share and use for designing software" 4 | layout: splash 5 | header: 6 | actions: 7 | - label: "Part of VirtualDDD.com" 8 | url: "https://virtualddd.com" 9 | --- 10 | 11 | > We all use heuristics (even if we haven’t articulated them to others) to discover, understand, explore, create, modify, or extend complex software systems. Billy Vaughn Koen, in Discussion of the Method: Conducting the Engineer’s Approach to Problem Solving, defines a heuristic as, “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. 12 | > 13 | > -Rebecca Wirfs-Brock 14 | 15 | Domain-Driven Design Heuristics is a community driven site to document and discuss about Design Heuristics. For now we divide into three different types of heuristics: 16 | 17 | * [Design Heuristics](/design-heuristics): Heuristics we use to solve a specific problem; 18 | * [Guiding Heuristics](/guiding-heuristics): Heuristics that guide our use of other heuristics (meta-heuristics, if you will); 19 | * [Value-based Heuristics](value-based-heuristics): Heuristics that determine our attitude and behavior towards design or the world and the way we work; 20 | 21 | Checkout the [Heuristics](/heuristics) tab. 22 | 23 | # Using the information 24 | 25 | All the information on this site is [Creative Commons Attribution-ShareAlike](https://creativecommons.org/licenses/by-sa/4.0/), please remix, adapt, and build upon the work on this site, even for commercial purposes, as long as you credit the authors and submitter and license your new creations under the identical terms. 26 | ![CC BY-SA](https://licensebuttons.net/l/by-sa/3.0/88x31.png) 27 | 28 | # Submit 29 | 30 | If you want to submit your own heuristics go to [Submit Heuristics](/submit) for explanations. 31 | 32 | If you have any questions please feel free to contact us trough email: submit@dddheuristic.com 33 | 34 | # Articles 35 | 36 | * [Growing Your Personal Design Heuristics Toolkit](http://wirfs-brock.com/blog/2019/03/20/growing-your-personal-design-heuristics/) by Rebecca Wirfs-Brock 37 | * [What do typical design heuristics look like?](http://wirfs-brock.com/blog/2019/04/04/what-do-typical-design-heuristics-look/) by Rebecca Wirfs-Brock 38 | * [Writing, Remembering, and Sharing Design Heuristics](http://wirfs-brock.com/blog/2019/04/12/writing/) by Rebecca Wirfs-Brock 39 | * [Architecture Clues: Heuristics, Part i. SCARS](https://www.linkedin.com/pulse/architecture-clues-heuristics-part-i-scars-ruth-malan/) by Ruth Malan 40 | * [Architecture Clues: Heuristics, Part ii. Decisions and Change](https://www.linkedin.com/pulse/architecture-clues-heuristics-part-ii-decisions-change-ruth-malan/) by Ruth Malan 41 | 42 | 43 | # Video's 44 | {% include video id="TP3xTZi_Qn8" provider="youtube" %} 45 | {% include video id="9ZgSz6xAfL8" provider="youtube" %} 46 | -------------------------------------------------------------------------------- /netlify.toml: -------------------------------------------------------------------------------- 1 | [build] 2 | command = "jekyll build" 3 | publish = "_site" 4 | 5 | [build.environment] 6 | JEKYLL_ENV = "production" 7 | --------------------------------------------------------------------------------