├── .gitignore ├── LICENCE.md ├── README.md ├── _config.yml ├── case-studies └── README.md ├── resources ├── ENWhirlpoolVSStarter.jpg ├── aggregate-design-canvas-v1.jpg ├── bounded-context-canvas-v3.jpeg ├── bounded-context-canvas-v4.jpeg ├── bounded-context-canvas-v5.jpg ├── business-model-canvas.png ├── context-map-cheat-sheet.png ├── context-map.jpg ├── core-domain-chart.jpg ├── ddd-starter-modeling-circular.svg ├── ddd-starter-modeling-steps.svg ├── ddd-starter-modelling-process-colored.png ├── ddd-starter-modelling-process.jpg ├── domain-message-flow.jpg ├── event_storm_sub_domains.png └── event_storming.jpeg └── translations ├── es └── resources │ └── ddd-starter-modelling-process-colored-ES.png ├── fr └── resources │ ├── ddd-starter-modeling-circular-FR.jpg │ └── ddd-starter-modelling-process-colored-FR.jpg ├── it └── resources │ └── ddd-starter-modelling-process-colored-IT.jpg ├── pt-br ├── README.md └── resources │ ├── bounded-context-canvas-v5.jpg │ └── ddd-starter-modeling-circular-pt-br.jpg └── zh-tw ├── README.md └── resources ├── ENWhirlpoolVSStarter.jpg ├── aggregate-design-canvas-v1.jpg ├── bounded-context-canvas-v3.jpeg ├── bounded-context-canvas-v4.jpeg ├── bounded-context-canvas-v5.jpg ├── business-model-canvas.png ├── context-map-cheat-sheet.png ├── context-map.jpg ├── core-domain-chart.jpg ├── ddd-starter-modelling-process-colored.png ├── ddd-starter-modelling-process.jpg ├── domain-message-flow.jpg ├── event_storm_sub_domains.png └── event_storming.jpeg /.gitignore: -------------------------------------------------------------------------------- 1 | .DS_Store 2 | .idea 3 | .vscode 4 | -------------------------------------------------------------------------------- /LICENCE.md: -------------------------------------------------------------------------------- 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 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Domain-Driven Design Starter Modelling Process 2 | 3 | This process gives you a step-by-step guide for learning and practically applying each aspect of Domain-Driven Design (DDD) - from orienting around an organisation's business model to coding a domain model. 4 | 5 | Using this process will guide you through each of the essential steps in designing a software system with the DDD mindset, so you can focus on your business challenges and not be overwhelmed by learning DDD at the same time. 6 | 7 | Once you have been through a few iterations of the process you will have the foundational DDD theory and practical experience to go deeper into DDD. Then you will be able to adapt and improve the process to suit your needs in any context. On a real project you'll often be jumping back and forth between these steps. 8 | 9 | > This process is for beginners. It is not a linear sequence of steps that you should standardise as a best practice. Domain-Driven Design is an evolutionary design process which necessitates continuous iteration on all aspects of knowledge and design. 10 | 11 | ![DDD Starter Modelling Process](resources/ddd-starter-modeling-circular.svg) 12 | 13 | __Navigation:__ 14 | 15 | - [Domain-Driven Design Starter Modelling Process](#domain-driven-design-starter-modelling-process) 16 | - [When to use the DDD Starter Modelling Process?](#when-to-use-the-ddd-starter-modelling-process) 17 | - [Kicking Off a Greenfield Project](#kicking-off-a-greenfield-project) 18 | - [Beginning a Brownfield Migration](#beginning-a-brownfield-migration) 19 | - [Kicking Off a Major Program of Work](#kicking-off-a-major-program-of-work) 20 | - [Explore Your Domain for New Learning Opportunities](#explore-your-domain-for-new-learning-opportunities) 21 | - [Assess Current State of Your Project](#assess-current-state-of-your-project) 22 | - [Re-organising Teams](#re-organising-teams) 23 | - [Practicing or Learning DDD](#practicing-or-learning-ddd) 24 | - [How to Adapt the Process?](#how-to-adapt-the-process) 25 | - [Start with Collaborative Modelling](#start-with-collaborative-modelling) 26 | - [Start by Assessing IT Landscape](#start-by-assessing-it-landscape) 27 | - [Code Before Confirming Architecture and Team Boundaries](#code-before-confirming-architecture-and-team-boundaries) 28 | - [Repeat Steps 2 (Discover) - 6 (Organise) Before Moving to 7 (Define)](#repeat-steps-2-discover---6-organise-before-moving-to-7-define) 29 | - [Organise Teams Before Designing Contexts](#organise-teams-before-designing-contexts) 30 | - [Blending Definition and Coding](#blending-definition-and-coding) 31 | - [The Process](#the-process) 32 | - [Understand](#understand) 33 | - [Tools](#tools) 34 | - [Who to Involve](#who-to-involve) 35 | - [Discover](#discover) 36 | - [Tools](#tools-1) 37 | - [Who to Involve](#who-to-involve-1) 38 | - [Decompose](#decompose) 39 | - [Tools](#tools-2) 40 | - [Who to Involve](#who-to-involve-2) 41 | - [Strategize](#strategize) 42 | - [Tools/Resources](#toolsresources) 43 | - [Who to Involve](#who-to-involve-3) 44 | - [Connect](#connect) 45 | - [Tools](#tools-3) 46 | - [Who to Involve](#who-to-involve-4) 47 | - [Organise](#organise) 48 | - [Tools](#tools-4) 49 | - [Who to Involve](#who-to-involve-5) 50 | - [Define](#define) 51 | - [Tools](#tools-5) 52 | - [Who to Involve](#who-to-involve-6) 53 | - [Code](#code) 54 | - [Tools](#tools-6) 55 | - [Who to Involve](#who-to-involve-7) 56 | - [How the DDD Starter Modelling Process relates to the Whirlpool Process](#how-the-ddd-starter-modelling-process-relates-to-the-whirlpool-process) 57 | - [Contributors](#contributors) 58 | - [Contributions and Feedback](#contributions-and-feedback) 59 | 60 | ## When to use the DDD Starter Modelling Process? 61 | 62 | If you're new to DDD or just not sure where to start, this process can reduce your cognitive load. It will guide you through following scenarios, and possibly others: 63 | 64 | ### Kicking Off a Greenfield Project 65 | 66 | At the start of a new project the number of things you need to think about can be overwhelming. One or two iterations of this process can help you put the foundations in place. 67 | 68 | ### Beginning a Brownfield Migration 69 | 70 | Before getting to work on modernising your legacy system, a few iterations of this process can help you to uncover essential information needed to create a vision for your target architecture. 71 | 72 | ### Kicking Off a Major Program of Work 73 | 74 | When starting a new initiative involves a significant investment across many teams, it is essential to cover the 8 steps in the process. This process can guide you through the first few iterations. 75 | 76 | ### Explore Your Domain for New Learning Opportunities 77 | 78 | Software development is a learning process. You can apply the DDD Starter Modelling Process at any time to uncover new insights, identify new opportunities, or simply share knowledge around the team. 79 | 80 | ### Assess Current State of Your Project 81 | 82 | This process can be the foundation for assessing how well your current system is aligned to the domain and business model. 83 | 84 | ### Re-organising Teams 85 | 86 | A loosely-coupled architecture enables teams to work in parallel without being blocked. A loosely-coupled architecture also must be aligned to coupling in the domain. This process will help you to design a software architecture, and a team structure aligned with your domain. 87 | 88 | ### Practicing or Learning DDD 89 | 90 | This process is ideal when you are new to DDD and want to practice, or you want to teach others the different aspects of modelling a domain. It's important to communicate that this linear process is not a realistic process. It's just a starting point to reduce cognitive load until you are confident with DDD. 91 | 92 | If you want to try it out yourself, colleagues at SAP have created a [DDD Kata](https://github.com/SAP/curated-resources-for-domain-driven-design/blob/main/ddd-kata.md) to educate teams, how to apply the DDD Modelling Process in your team. Based upon a set of requirements, you can try out how EventStorming, Domain Message Flow, Bounded Context Canvas and Aggregate Canvas work together and help you to validate your design decisions. 93 | 94 | ## How to Adapt the Process? 95 | 96 | This process can be customised in many ways. On a real project, you'll be switching between all 8 steps based on the new insights you gain or need to gain. 97 | 98 | Below are a few reasons for deciding when to change the order or switch between steps. 99 | 100 | ### Start with Collaborative Modelling 101 | 102 | If you want to get your whole team collaborating immediately, modelling the domain which they are familiar with might be more comfortable than talking about business models and strategy which they are less comfortable with. 103 | 104 | ### Start by Assessing IT Landscape 105 | 106 | Before looking forward to the business vision and going deep into the domain, it might be better to visualise the existing architecture first. Start with step 5 and map out your strategic portfolio to see what the major constraints you will face are. 107 | 108 | ### Code Before Confirming Architecture and Team Boundaries 109 | 110 | On some projects it makes sense to start by writing code sooner. Perhaps you need to deliver an MVP or the domain is so complex that creating a model in code is necessary before you can consider the architecture. 111 | 112 | ### Repeat Steps 2 (Discover) - 6 (Organise) Before Moving to 7 (Define) 113 | 114 | Before you dive into the definition of individual bounded contexts, it may be beneficial to model the domain multiple times and look for different ways to decompose your system into sub-domains and teams. 115 | 116 | ### Organise Teams Before Designing Contexts 117 | 118 | For a great deal of projects there are organisational constraints that we need to take into account. If this is the case, you should consider identifying possible team structures before designing architectures that you will never be able to implement. 119 | 120 | ### Blending Definition and Coding 121 | 122 | Steps 7 (Define) and 8 (Code) can occur concurrently. This may happen when you are coding a bounded context, and the insights you get from writing code make you change the high-level design. 123 | 124 | ## The Process 125 | 126 | The modelling process is composed of 8 steps which are introduced below. 127 | 128 | A good talk that gives an overview of the process in the context of typical phases of designing sociotechnical architectures is ["Sociotechnical Architecture: co-designing technical & organizational architecture to maximize impact"](https://www.youtube.com/watch?v=ekMPm78KFj0&feature=youtu.be&t=1820) by [Eduardo da Silva](https://twitter.com/emgsilva). Eduardo groups the activities of the process and its 8 steps in [four distinct phases](https://speakerdeck.com/emgsilva/intro-to-sociotechnical-architecture-co-designing-technical-and-organizational-architecture-to-maximize-impact?slide=31), namely: 129 | 130 | 1. Align & Understand 131 | 2. Strategic Architecture 132 | 3. Strategy & Org Design 133 | 4. Tactical Architecture. 134 | 135 | ### Understand 136 | 137 | Align our focus with the organisation's business model, the needs of its users, and its short, medium, and long-term goals. 138 | 139 | Every decision we take regarding the architecture, the code, or the organisation has business and user consequences. In order to design, build, and evolve software systems most effectively, our decisions need to create the optimal business impact, which can only be achieved if we are aligned to the business goals, as well as supporting the users current and potential future needs. 140 | 141 | Badly designed architecture and/or boundaries can have a negative impact or even make it impossible to achieve these goals. 142 | 143 | As a starting point, we recommend [The Business Model Canvas](https://www.strategyzer.com/canvas/business-model-canvas) for the business perspective, [User Story Mapping](https://www.jpattonassociates.com/user-story-mapping/) for understanding the user vantage point. 144 | 145 | ![The Business Model Canvas](resources/business-model-canvas.png) 146 | 147 | #### Tools 148 | 149 | - [Impact Mapping](https://www.impactmapping.org/) 150 | - [The Business Model Canvas](https://www.strategyzer.com/canvas/business-model-canvas) 151 | - [The Product Strategy Canvas](https://melissaperri.com/blog/2016/07/14/what-is-good-product-strategy) 152 | - [Wardley Mapping](https://learnwardleymapping.com/) 153 | - [User Story Mapping](https://www.jpattonassociates.com/user-story-mapping/) 154 | 155 | #### Who to Involve 156 | 157 | - People who design, build, test software 158 | - People who have domain knowledge 159 | - People who understand the product and business strategy 160 | - Real end users, not only their representatives in your organisation 161 | 162 | ### Discover 163 | 164 | Discover the domain visually and collaboratively. 165 | 166 | This is the most crucial aspect of DDD. You cannot skip discovery. If your whole team doesn't build up a good understanding of the domain, all software decisions will be misguided. 167 | 168 | Spreading domain knowledge through the whole team will create a shared understanding. It enables the developers to build a software system aligned to the domain which can be more flexible to incorporate future business changes. 169 | 170 | Ensuring that domain knowledge is spread across the whole team enables its members to contribute with ideas for improving the product. 171 | 172 | > #### Discovery is Continuous 173 | > 174 | > Teams who are successful with DDD are practicing discovery techniques on a frequent basis. There is always more to learn about the domain. 175 | > 176 | > When first attempting discovery, a facilitator who is experienced with techniques like EventStorming can help a team to see the true benefits of discovery beyond a superficial level. 177 | > 178 | > We strongly encourage you to check out [Visual Collaboration Tools](https://leanpub.com/visualcollaborationtools). 179 | 180 | As a starting point, we recommend [EventStorming](https://www.eventstorming.com/). 181 | 182 | ![EventStorming](resources/event_storming.jpeg) 183 | 184 | #### Tools 185 | 186 | - [Domain Storytelling](https://domainstorytelling.org/) 187 | - [Example Mapping](https://cucumber.io/blog/bdd/example-mapping-introduction/) 188 | - [EventStorming](https://www.eventstorming.com/) 189 | - [User Journey Mapping](https://boagworld.com/audio/customer-journey-mapping/) 190 | - [User Story Mapping](https://www.jpattonassociates.com/user-story-mapping/) 191 | 192 | #### Who to Involve 193 | 194 | - People who design, build, test software 195 | - People who have domain knowledge 196 | - People who understand product and business strategy 197 | - People who understand the customers' needs and problems 198 | - Real end users 199 | 200 | ### Decompose 201 | 202 | Decompose the domain into sub-domains - loosely-coupled parts of the domain. 203 | 204 | We decompose a large problem domain into sub-domains for a few key reasons: 205 | 206 | - reduced cognitive load, so that we can reason about parts of the domain independently, 207 | - give development teams autonomy, so that they can work on separate parts of the solution, 208 | - identifying loose-coupling and high-cohesion in the domain which carries over to our software architecture and team structure. 209 | 210 | As a starting point, we recommend carving up your event storm into sub-domains and [Context Maps](https://speakerdeck.com/mploed/visualizing-sociotechnical-architectures-with-context-maps). 211 | 212 | ![Sub-domains on an EventStorm](resources/event_storm_sub_domains.png)*Credit: Alberto Brandolini* 213 | 214 | #### Tools 215 | 216 | - [Business Capability Modelling](https://www.slideshare.net/trondhr/from-capabilities-to-services-modelling-for-businessit-alignment-v2) 217 | - [Design Heuristics](https://www.dddheuristics.com/) 218 | - [EventStorming with sub-domains](https://www.eventstorming.com/) 219 | - [Independent Service Heuristics](https://github.com/TeamTopologies/Independent-Service-Heuristics) 220 | - [Visualising Sociotechnical Architecture with Context Maps](https://speakerdeck.com/mploed/visualizing-sociotechnical-architectures-with-context-maps) 221 | 222 | #### Who to Involve 223 | 224 | - People who design, build, test software 225 | - People who have domain knowledge 226 | 227 | ### Strategize 228 | 229 | Strategically map out your sub-domains to identify core domains: the parts of the domain which have the greatest potential for business differentiation or strategic significance. 230 | 231 | Time and resources are limited, so understanding which parts of the domain to focus on is critical to delivering optimal business impact. 232 | 233 | By analysing what your core domains are, you will have a better idea of how much quality and rigour is required to build each part of your system, and you'll be able to make highly-educated build vs buy vs outsource decisions. 234 | 235 | As a starting point, we recommend [Core Domain Charts](https://github.com/ddd-crew/core-domain-charts). 236 | 237 | ![Core Domain Charts](resources/core-domain-chart.jpg) 238 | 239 | #### Tools/Resources 240 | 241 | - [Core Domain Charts](https://github.com/ddd-crew/core-domain-charts) 242 | - [Purpose Alignment Model](https://www.informit.com/articles/article.aspx?p=1384195&seqNum=2) 243 | - [Wardley Mapping](https://learnwardleymapping.com/) 244 | - [Revisiting the Basics of Domain-Driven Design](https://vladikk.com/2018/01/26/revisiting-the-basics-of-ddd/) 245 | 246 | #### Who to Involve 247 | 248 | - People who understand product and business strategy 249 | - People who design, build, test software 250 | - People who have domain knowledge 251 | 252 | ### Connect 253 | 254 | Connect the sub-domains into a loosely-coupled architecture which fulfills end-to-end business use-cases. 255 | 256 | It is imperative to not only decompose a large domain into parts but to also carefully design the interactions between those parts to minimise unwanted coupling and complexity. It is necessary to challenge the initial design by applying concrete use-cases to uncover hidden complexity. 257 | 258 | As a starting point, we recommend [Domain Message Flow Modelling](https://github.com/ddd-crew/domain-message-flow-modelling). 259 | 260 | ![Domain Message Flow Modelling](resources/domain-message-flow.jpg) 261 | 262 | #### Tools 263 | 264 | - [Business Process Model and Notation](https://en.wikipedia.org/wiki/Business_Process_Model_and_Notation) 265 | - [Domain Message Flow Modelling](https://github.com/ddd-crew/domain-message-flow-modelling) 266 | - [Process Modelling EventStorming](https://www.eventstorming.com/) 267 | - [Sequence Diagrams](https://en.wikipedia.org/wiki/Sequence_diagram) 268 | 269 | #### Who to Involve 270 | 271 | - People who design, build, test software 272 | - People who have domain knowledge 273 | 274 | ### Organise 275 | 276 | Organise autonomous teams that are optimised for fast flow and aligned with context boundaries. 277 | 278 | Teams need to be organised to have autonomy, clear goals and sense of purpose. In order to do that we need to take into account organisational constraints, so that teams organise themselves for fast flow. 279 | 280 | > #### Team Self-organisation 281 | > 282 | > Organisation is not something that is done to teams, rather teams should be involved in the process of defining their boundaries, interactions, and responsibilities. 283 | > 284 | > Some companies like Red Gate Software empower and trust their teams to [fully organise themselves](https://medium.com/ingeniouslysimple/how-redgate-ran-its-first-team-self-selection-process-4bfac721ae2). 285 | 286 | We can optimise how people collaborate with each other if we align teams with context boundaries. In order to right-size the teams we need to take into account available talent, cognitive load, communication overhead, and bus factor. 287 | 288 | As a starting point, we recommend visualising sociotechnical architecture with the [Context Maps](https://speakerdeck.com/mploed/visualizing-sociotechnical-architectures-with-context-maps). A brief overview of the most important patterns can be found under the [context-mapping](https://github.com/ddd-crew/context-mapping) GitHub Project. 289 | 290 | ![Context Map](resources/context-map-cheat-sheet.png)*Credit: Michael Plöd* 291 | 292 | #### Tools 293 | 294 | - [Dynamic Reteaming](https://leanpub.com/dynamicreteaming) 295 | - [Explorers, Villagers & Town Planners](https://medium.com/mappingpractice/how-to-organise-yourself-f36f084a611b) 296 | - [Team Topologies](https://teamtopologies.com/) 297 | - [Visualising Sociotechnical Architecture with Context Maps](https://speakerdeck.com/mploed/visualizing-sociotechnical-architectures-with-context-maps) 298 | 299 | #### Who to Involve 300 | 301 | - People who design, build, test software 302 | - People who have domain knowledge 303 | - People who understand the product and business strategy 304 | 305 | ### Define 306 | 307 | Define the roles and responsibilities of each [bounded context](https://martinfowler.com/bliki/BoundedContext.html). 308 | 309 | Before committing to a design, make explicit decisions about the choices which can have a significant impact on the overall design. Have these conversations early while it is still easy to change your mind and explore alternative models. 310 | 311 | Design collaboratively and visually, and start to consider the technical limitations so that you can uncover constraints or opportunities. 312 | 313 | As a starting point, we recommend the [Bounded Context Canvas](https://github.com/ddd-crew/bounded-context-canvas). 314 | 315 | ![Bounded Context Canvas](resources/bounded-context-canvas-v5.jpg) 316 | 317 | #### Tools 318 | 319 | - [Bounded Context Canvas](https://github.com/ddd-crew/bounded-context-canvas) 320 | - [C4 System Context Diagram](https://c4model.com/#SystemContextDiagram) 321 | - [Quality Storming](https://speakerdeck.com/mploed/quality-storming) 322 | 323 | #### Who to Involve 324 | 325 | - People who design, build, test software 326 | - People who have domain knowledge 327 | - People who are responsible for the product 328 | 329 | ### Code 330 | 331 | Code the domain model. 332 | 333 | Aligning the code to the domain makes it easier to change the code when the domain changes. By collaboratively modelling the problem space with experts, the developers have a chance to learn about the domain and minimise misunderstandings. 334 | 335 | As a starting point, we recommend the [Aggregate Design Canvas](https://github.com/ddd-crew/aggregate-design-canvas). 336 | 337 | ![Aggregate Design Canvas](resources/aggregate-design-canvas-v1.jpg) 338 | 339 | #### Tools 340 | 341 | - [Aggregate Design Canvas](https://github.com/ddd-crew/aggregate-design-canvas) 342 | - [C4 Component Diagrams](https://c4model.com/#ComponentDiagram) 343 | - [Design-Level EventStorming](https://www.eventstorming.com/) 344 | - [Event Modeling](https://eventmodeling.org/posts/what-is-event-modeling/) 345 | - [Hexagonal Architecture](https://en.wikipedia.org/wiki/Hexagonal_architecture_(software)) 346 | - [Mob Programming](https://mobprogramming.org/) 347 | - [Model Exploration Whirlpool](https://domainlanguage.com/ddd/whirlpool/) 348 | - [Onion Architecture](https://jeffreypalermo.com/2008/07/the-onion-architecture-part-1/) 349 | - [Unified Modelling Language](https://en.wikipedia.org/wiki/Unified_Modeling_Language) 350 | 351 | #### Who to Involve 352 | 353 | - People who design, build, test software 354 | 355 | ### How the DDD Starter Modelling Process relates to the Whirlpool Process 356 | 357 | Some of you might have noticed some similarities with Eric Evans' [Whirlpool Process](https://www.domainlanguage.com/ddd/whirlpool/). And indeed, both are guides and not rigid best-practices. They're also both continuous and iterative. 358 | But the DDD Starter Modelling Process covers more than the Whirlpool process by aiming at building a socio-technical architecture. 359 | The picture below shows a possible overlap between the two processes. 360 | 361 | ![WhirlpoolVSStarter](resources/ENWhirlpoolVSStarter.jpg) 362 | 363 | Needless to say that Eric Evan's Whirlpool process remains totally relevant today and gives people highly valuable insights and guidance on how to explore models. 364 | 365 | ## Contributors 366 | 367 | Thanks to all [existing and future contributors](https://github.com/ddd-crew/ddd-starter-modelling-process/graphs/contributors) and to the following individuals who have all contributed to the DDD Starter Modelling Process: 368 | 369 | - [Ciaran McNulty](https://github.com/ciaranmcnulty) 370 | - [Eduardo da Silva](https://github.com/emgsilva) 371 | - [Gien Verschatse](https://twitter.com/selketjah) 372 | - [James Morcom](https://twitter.com/morcs) 373 | - [Maxime Sanglan-Charlier](https://twitter.com/__MaxS__) 374 | 375 | ## Contributions and Feedback 376 | 377 | The Domain-Driven Design Starter Modelling Process is freely available for you to use. In addition, your feedback and ideas are welcome to improve the technique or to create alternative versions. 378 | 379 | If you have questions you can ping us or open an [Issue](https://github.com/ddd-crew/ddd-starter-modelling-process/issues/new/choose). 380 | 381 | Feel free to also send us pull requests with your [case studies](/case-studies). 382 | 383 | [![CC BY 4.0][cc-by-shield]][cc-by] 384 | 385 | This work is licensed under a [Creative Commons Attribution 4.0 International 386 | License][cc-by]. 387 | 388 | [![CC BY 4.0][cc-by-image]][cc-by] 389 | 390 | [cc-by]: http://creativecommons.org/licenses/by/4.0/ 391 | [cc-by-image]: https://i.creativecommons.org/l/by/4.0/88x31.png 392 | [cc-by-shield]: https://img.shields.io/badge/License-CC%20BY%204.0-lightgrey.svg 393 | -------------------------------------------------------------------------------- /_config.yml: -------------------------------------------------------------------------------- 1 | plugins: 2 | - jekyll-relative-links 3 | relative_links: 4 | enabled: true 5 | collections: true 6 | include: 7 | - README.md 8 | - LICENSE.md 9 | - COPYING.md 10 | - CODE_OF_CONDUCT.md 11 | - CONTRIBUTING.md 12 | 13 | theme: jekyll-theme-architect 14 | -------------------------------------------------------------------------------- /case-studies/README.md: -------------------------------------------------------------------------------- 1 | # Case studies 2 | 3 | **** 4 | _Add your case studies in a subdirectory and link them to this page._ 5 | 6 | ## Title 7 | Short teaser (why should others read it?), including a link 8 | **** 9 | -------------------------------------------------------------------------------- /resources/ENWhirlpoolVSStarter.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ddd-crew/ddd-starter-modelling-process/7190272f5964c8bce749ddf06367c5afe72c85db/resources/ENWhirlpoolVSStarter.jpg -------------------------------------------------------------------------------- /resources/aggregate-design-canvas-v1.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ddd-crew/ddd-starter-modelling-process/7190272f5964c8bce749ddf06367c5afe72c85db/resources/aggregate-design-canvas-v1.jpg -------------------------------------------------------------------------------- /resources/bounded-context-canvas-v3.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ddd-crew/ddd-starter-modelling-process/7190272f5964c8bce749ddf06367c5afe72c85db/resources/bounded-context-canvas-v3.jpeg -------------------------------------------------------------------------------- /resources/bounded-context-canvas-v4.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ddd-crew/ddd-starter-modelling-process/7190272f5964c8bce749ddf06367c5afe72c85db/resources/bounded-context-canvas-v4.jpeg -------------------------------------------------------------------------------- /resources/bounded-context-canvas-v5.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ddd-crew/ddd-starter-modelling-process/7190272f5964c8bce749ddf06367c5afe72c85db/resources/bounded-context-canvas-v5.jpg -------------------------------------------------------------------------------- /resources/business-model-canvas.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ddd-crew/ddd-starter-modelling-process/7190272f5964c8bce749ddf06367c5afe72c85db/resources/business-model-canvas.png -------------------------------------------------------------------------------- /resources/context-map-cheat-sheet.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ddd-crew/ddd-starter-modelling-process/7190272f5964c8bce749ddf06367c5afe72c85db/resources/context-map-cheat-sheet.png -------------------------------------------------------------------------------- /resources/context-map.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ddd-crew/ddd-starter-modelling-process/7190272f5964c8bce749ddf06367c5afe72c85db/resources/context-map.jpg -------------------------------------------------------------------------------- /resources/core-domain-chart.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ddd-crew/ddd-starter-modelling-process/7190272f5964c8bce749ddf06367c5afe72c85db/resources/core-domain-chart.jpg -------------------------------------------------------------------------------- /resources/ddd-starter-modelling-process-colored.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ddd-crew/ddd-starter-modelling-process/7190272f5964c8bce749ddf06367c5afe72c85db/resources/ddd-starter-modelling-process-colored.png -------------------------------------------------------------------------------- /resources/ddd-starter-modelling-process.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ddd-crew/ddd-starter-modelling-process/7190272f5964c8bce749ddf06367c5afe72c85db/resources/ddd-starter-modelling-process.jpg -------------------------------------------------------------------------------- /resources/domain-message-flow.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ddd-crew/ddd-starter-modelling-process/7190272f5964c8bce749ddf06367c5afe72c85db/resources/domain-message-flow.jpg -------------------------------------------------------------------------------- /resources/event_storm_sub_domains.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ddd-crew/ddd-starter-modelling-process/7190272f5964c8bce749ddf06367c5afe72c85db/resources/event_storm_sub_domains.png -------------------------------------------------------------------------------- /resources/event_storming.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ddd-crew/ddd-starter-modelling-process/7190272f5964c8bce749ddf06367c5afe72c85db/resources/event_storming.jpeg -------------------------------------------------------------------------------- /translations/es/resources/ddd-starter-modelling-process-colored-ES.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ddd-crew/ddd-starter-modelling-process/7190272f5964c8bce749ddf06367c5afe72c85db/translations/es/resources/ddd-starter-modelling-process-colored-ES.png -------------------------------------------------------------------------------- /translations/fr/resources/ddd-starter-modeling-circular-FR.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ddd-crew/ddd-starter-modelling-process/7190272f5964c8bce749ddf06367c5afe72c85db/translations/fr/resources/ddd-starter-modeling-circular-FR.jpg -------------------------------------------------------------------------------- /translations/fr/resources/ddd-starter-modelling-process-colored-FR.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ddd-crew/ddd-starter-modelling-process/7190272f5964c8bce749ddf06367c5afe72c85db/translations/fr/resources/ddd-starter-modelling-process-colored-FR.jpg -------------------------------------------------------------------------------- /translations/it/resources/ddd-starter-modelling-process-colored-IT.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ddd-crew/ddd-starter-modelling-process/7190272f5964c8bce749ddf06367c5afe72c85db/translations/it/resources/ddd-starter-modelling-process-colored-IT.jpg -------------------------------------------------------------------------------- /translations/pt-br/README.md: -------------------------------------------------------------------------------- 1 | # Domain-Driven Design Starter Modelling Process 2 | 3 | Esse processo lhe oferece um guia passo a passo para aprender e aplicar na prática cada aspecto do Domain-Driven Design (DDD) - desde a orientação em torno do modelo de negócios de uma organização até a codificação de um modelo de domínio. 4 | 5 | O uso desse processo o guiará por cada uma das etapas essenciais do projeto de um sistema de software com a mentalidade DDD, para que você possa se concentrar nos desafios do seu negócio e não se sobrecarregar com o aprendizado do DDD ao mesmo tempo. 6 | 7 | Depois de passar por algumas iterações do processo, você terá a teoria básica do DDD e a experiência prática para se aprofundar no DDD. Em seguida, poderá adaptar e aprimorar o processo para atender às suas necessidades em qualquer contexto. Em um projeto real, muitas vezes você estará alternando entre essas etapas. 8 | 9 | > Esse processo é para iniciantes. Não é uma sequência linear de etapas que você deva padronizar como prática recomendada. O Domain-Driven Design é um processo de design evolutivo que exige iteração contínua em todos os aspectos do conhecimento e do design. 10 | 11 | ![Processo de modelagem inicial do DDD](resources/ddd-starter-modeling-circular-pt-br.jpg) 12 | 13 | __Navegação:__ 14 | 15 | - [Domain-Driven Design Starter Modelling Process](#domain-driven-design-starter-modelling-process) 16 | - [Quando usar o "Domain-Driven Design Starter Modelling Process"?](#quando-usar-o-domain-driven-design-starter-modelling-process) 17 | - [Iniciando um projeto "Greenfield"](#iniciando-um-projeto-greenfield) 18 | - [Iniciando uma migração "Brownfield"](#iniciando-uma-migração-brownfield) 19 | - [Iniciando um programa significantemente grande](#iniciando-um-programa-significantemente-grande) 20 | - [Explore seu domínio para obter novas oportunidades de aprendizado](#explore-seu-domínio-para-obter-novas-oportunidades-de-aprendizado) 21 | - [Avalie o estado atual de seu projeto](#avalie-o-estado-atual-de-seu-projeto) 22 | - [Reorganizando times](#reorganizando-times) 23 | - [Praticando ou aprendendo DDD](#praticando-ou-aprendendo-ddd) 24 | - [Como adaptar o processo?](#como-adaptar-o-processo) 25 | - [Começando com a modelagem colaborativa](#começando-com-a-modelagem-colaborativa) 26 | - [Começando pela avaliação do cenário de TI](#começando-pela-avaliação-do-cenário-de-ti) 27 | - [Codificando antes de confirmar a arquitetura e as fronteiras dos times](#codificando-antes-de-confirmar-a-arquitetura-e-as-fronteiras-dos-times) 28 | - [Repita as etapas 2 (Descobrir) - 6 (Organizar) antes de passar para a 7 (Definir)](#repita-as-etapas-2-descobrir---6-organizar-antes-de-passar-para-a-7-definir) 29 | - [Organizando os times antes de definir os contextos](#organizando-os-times-antes-de-definir-os-contextos) 30 | - [Mesclando Definição e Codificação](#mesclando-definição-e-codificação) 31 | - [O processo](#o-processo) 32 | - [Alinhar](#alinhar) 33 | - [Ferramentas](#ferramentas) 34 | - [Quem involver](#quem-involver) 35 | - [Descobrir](#descobrir) 36 | - [Ferramentas](#ferramentas-1) 37 | - [Quem involver](#quem-involver-1) 38 | - [Decompor](#decompor) 39 | - [Ferramentas](#ferramentas-2) 40 | - [Quem involver](#quem-involver-2) 41 | - [Criar Estratégia](#criar-estratégia) 42 | - [Ferramentas/Recursos](#ferramentasrecursos) 43 | - [Quem involver](#quem-involver-3) 44 | - [Conectar](#conectar) 45 | - [Ferramentas](#ferramentas-3) 46 | - [Quem involver](#quem-involver-4) 47 | - [Organizar](#organizar) 48 | - [Ferramentas](#ferramentas-4) 49 | - [Quem involver](#quem-involver-5) 50 | - [Definir](#definir) 51 | - [Ferramentas](#ferramentas-5) 52 | - [Quem involver](#quem-involver-6) 53 | - [Codificar](#codificar) 54 | - [Ferramentas](#ferramentas-6) 55 | - [Quem involver](#quem-involver-7) 56 | - [Como o "Domain-Driven Design Starter Modelling Process" se relaciona com o processo Whirlpool](#como-o-domain-driven-design-starter-modelling-process-se-relaciona-com-o-processo-whirlpool) 57 | - [Contribuidores](#contribuidores) 58 | - [Contribuições e Feedback](#contribuições-e-feedback) 59 | 60 | ## Quando usar o "Domain-Driven Design Starter Modelling Process"? 61 | 62 | Se você é novo no DDD ou não sabe por onde começar, esse processo pode reduzir sua carga cognitiva. Ele o guiará pelos cenários a seguir e possivelmente por outros: 63 | 64 | ### Iniciando um projeto "Greenfield" 65 | 66 | No início de um novo projeto, o número de coisas em que você precisa pensar pode ser muito grande. Uma ou duas iterações desse processo podem ajudá-lo a estabelecer a fundação. 67 | 68 | ### Iniciando uma migração "Brownfield" 69 | 70 | Antes de começar a trabalhar na modernização do sistema legado, algumas iterações desse processo podem ajudá-lo a descobrir as informações essenciais necessárias para criar uma visão da arquitetura futura. 71 | 72 | ### Iniciando um programa significantemente grande 73 | 74 | Quando o início de uma nova iniciativa envolve um investimento significativo em várias equipes, é essencial cobrir as 8 etapas do processo. Esse processo pode orientá-lo durante as primeiras iterações. 75 | 76 | ### Explore seu domínio para obter novas oportunidades de aprendizado 77 | 78 | O desenvolvimento de software é um processo de aprendizado. Você pode aplicar o "Domain-Driven Design Starter Modelling Process" a qualquer momento para descobrir novos insights, identificar novas oportunidades ou simplesmente compartilhar conhecimento com o seu time. 79 | 80 | ### Avalie o estado atual de seu projeto 81 | 82 | Esse processo pode ser a base para avaliar se o seu sistema atual está alinhado ao domínio e ao modelo de negócios. 83 | 84 | ### Reorganizando times 85 | 86 | Uma arquitetura com baixo acoplamento permite que as equipes trabalhem em paralelo sem serem bloqueadas. Uma arquitetura com baixo acoplamento também deve estar alinhada ao acoplamento no domínio. Esse processo o ajudará a projetar uma arquitetura de software e uma estrutura de equipe alinhadas ao seu domínio. 87 | 88 | ### Praticando ou aprendendo DDD 89 | 90 | Esse processo é ideal quando você é novo no DDD e quer praticar, ou quando quer ensinar aos outros os diferentes aspectos da modelagem de um domínio. É importante comunicar que esse processo linear não é um processo realista. É apenas um ponto de partida para reduzir a carga cognitiva até que você se sinta confiante com o DDD. 91 | 92 | Se quiser tentar, os colegas da SAP criaram um [DDD Kata](https://github.com/SAP/curated-resources-for-domain-driven-design/blob/main/ddd-kata.md) para ensinar como aplicar o Processo de Modelagem DDD em seu time. Com base em um conjunto de requisitos, você pode tentar algumas ferramentas como o EventStorming, o Domain Message Flow, o Bounded Context Canvas e o Aggregate Canvas, trabalhar juntos e validar suas decisões de design. 93 | 94 | ## Como adaptar o processo? 95 | 96 | Esse processo pode ser personalizado de várias maneiras. Em um projeto real, você alternará entre as 8 etapas com base nas suas percepções durante a jornada. 97 | 98 | Abaixo estão alguns motivos para decidir quando alterar a ordem ou alternar entre as etapas. 99 | 100 | ### Começando com a modelagem colaborativa 101 | 102 | Se você quiser que todo time colabore imediatamente, modelar o domínio com o qual eles estão familiarizados pode ser mais confortável do que falar sobre modelos de negócios e estratégias com os quais eles ainda não conhecem. 103 | 104 | ### Começando pela avaliação do cenário de TI 105 | 106 | Antes de se preocupar com a visão de negócios e se aprofundar no domínio, talvez seja melhor visualizar primeiro a arquitetura existente. Comece com a etapa 5 e mapeie seu portfólio estratégico para ver quais são as principais restrições que você enfrentará. 107 | 108 | ### Codificando antes de confirmar a arquitetura e as fronteiras dos times 109 | 110 | Em alguns projetos, faz sentido começar a codificar primeiro. Talvez você precise entregar um MVP ou o domínio seja tão complexo que seja necessário criar um modelo em código antes de considerar a arquitetura. 111 | 112 | ### Repita as etapas 2 (Descobrir) - 6 (Organizar) antes de passar para a 7 (Definir) 113 | 114 | Antes de se aprofundar na definição de contextos delimitados (Bounded Contexts), pode ser útil modelar o domínio várias vezes e procurar maneiras diferentes de decompor o sistema em subdomínios e times. 115 | 116 | ### Organizando os times antes de definir os contextos 117 | 118 | Em muitos projetos, há restrições organizacionais que precisam ser levadas em conta. Se esse for o caso, você pode considerar as estruturas de times ao invés de projetar arquiteturas que nunca conseguirá implementar. 119 | 120 | ### Mesclando Definição e Codificação 121 | 122 | As etapas 7 (Definir) e 8 (Codificar) podem ocorrer simultaneamente. Isso pode acontecer quando você está codificando um contexto delimitado (Bounded Context) e os insights que obtém ao escrever o código fazem com que você altere o design geral. 123 | 124 | ## O processo 125 | 126 | O processo de modelagem é composto de 8 etapas que são apresentadas a seguir. 127 | 128 | Uma boa palestra que oferece uma visão geral do processo no contexto das fases típicas do projeto de arquiteturas sociotécnicas é ["Sociotechnical Architecture: co-designing technical & organizational architecture to maximize impact"](https://www.youtube.com/watch?v=ekMPm78KFj0&feature=youtu.be&t=1820) de [Eduardo da Silva](https://twitter.com/emgsilva). Eduardo agrupa as atividades do processo e suas 8 etapas em [quatro fases distintas](https://speakerdeck.com/emgsilva/intro-to-sociotechnical-architecture-co-designing-technical-and-organizational-architecture-to-maximize-impact?slide=31), nomeadas: 129 | 130 | 1. Alinhar & Compreender. 131 | 2. Arquitetura Estratégica. 132 | 3. Estratégia e Design Organizacional. 133 | 4. Arquitetura Tática. 134 | 135 | ### Alinhar 136 | 137 | Alinhar nosso foco com o modelo de negócios da organização, as necessidades de seus usuários e suas metas de curto, médio e longo prazo. 138 | 139 | Cada decisão que tomamos em relação à arquitetura, ao código ou à organização tem consequências para os negócios e para os usuários. Para projetar, criar e desenvolver sistemas de software de forma mais eficaz, nossas decisões precisam criar o impacto comercial ideal, o que só pode ser alcançado se estivermos alinhados com as metas de negócio, além de dar suporte às necessidades atuais e futuras potenciais dos usuários. 140 | 141 | A arquitetura e/ou os contextos delimitados mal projetados podem ter um impacto negativo ou até mesmo impossibilitar o alcance desses objetivos. 142 | 143 | Como ponto de partida, recomendamos [The Business Model Canvas](https://www.strategyzer.com/canvas/business-model-canvas) para a perspectiva de negócio, [User Story Mapping](https://www.jpattonassociates.com/user-story-mapping/) para entender o ponto de vista do usuário. 144 | 145 | ![O "Business Model Canvas"](/resources/business-model-canvas.png) 146 | 147 | #### Ferramentas 148 | 149 | - [Impact Mapping](https://www.impactmapping.org/) 150 | - [O "Business Model Canvas"](https://www.strategyzer.com/canvas/business-model-canvas) 151 | - [O "Product Strategy Canvas"](https://melissaperri.com/blog/2016/07/14/what-is-good-product-strategy) 152 | - [Wardley Mapping](https://learnwardleymapping.com/) 153 | - [User Story Mapping](https://www.jpattonassociates.com/user-story-mapping/) 154 | 155 | #### Quem involver 156 | 157 | - Pessoas que projetam, criam e testam software 158 | - Pessoas que têm conhecimento do domínio 159 | - Pessoas que entendem o produto e a estratégia de negócios 160 | - Usuários finais reais, não apenas seus representantes em sua organização 161 | 162 | ### Descobrir 163 | 164 | Descubra o domínio de forma visual e colaborativa. 165 | 166 | Esse é o aspecto mais importante do DDD. Não se pode ignorar a descoberta. Se toda a sua equipe não tiver um bom entendimento do domínio, todas as decisões de software serão mal orientadas. 167 | 168 | A disseminação do conhecimento do domínio por toda a equipe criará um entendimento compartilhado. Isso permite que os desenvolvedores criem um sistema de software alinhado ao domínio, que pode ser mais flexível para incorporar futuras mudanças nos negócios. 169 | 170 | Garantir que o conhecimento do domínio seja disseminado por toda a equipe permite que seus membros contribuam com ideias para melhorar o produto. 171 | 172 | > #### A descoberta é contínua 173 | > 174 | > Os times que têm sucesso com o DDD praticam técnicas de descoberta com frequência. Sempre há mais a aprender sobre o domínio. 175 | > 176 | > Na primeira tentativa de descoberta, um facilitador pode usar técnicas como o EventStorming pode ajudar o time a ver os verdadeiros benefícios da descoberta além de um nível superficial. 177 | > 178 | > Recomendamos que você dê uma olhada em [Visual Collaboration Tools](https://leanpub.com/visualcollaborationtools). 179 | 180 | Como ponto de partida, recomendamos [EventStorming](https://www.eventstorming.com/). 181 | 182 | ![EventStorming](/resources/event_storming.jpeg) 183 | 184 | #### Ferramentas 185 | 186 | - [Domain Storytelling](https://domainstorytelling.org/) 187 | - [Example Mapping](https://cucumber.io/blog/bdd/example-mapping-introduction/) 188 | - [EventStorming](https://www.eventstorming.com/) 189 | - [User Journey Mapping](https://boagworld.com/audio/customer-journey-mapping/) 190 | - [User Story Mapping](https://www.jpattonassociates.com/user-story-mapping/) 191 | 192 | #### Quem involver 193 | 194 | - Pessoas que projetam, criam e testam software 195 | - Pessoas que têm conhecimento do domínio 196 | - Pessoas que entendem de estratégia de produtos e negócios 197 | - Pessoas que entendem as necessidades e os problemas dos clientes 198 | - Usuários finais reais 199 | 200 | ### Decompor 201 | 202 | Decompor o domínio em subdomínios - partes do domínio com baixo acoplamento. 203 | 204 | Decompomos um domínio maior de problemas em subdomínios por alguns motivos importantes: 205 | 206 | - carga cognitiva reduzida, para que possamos raciocinar sobre partes do domínio de forma independente, 207 | - dar autonomia aos times de desenvolvimento, para que eles possam trabalhar em partes separadas da solução, 208 | - identificar o baixo acoplamento e a alta coesão no domínio, o que é transferido para nossa arquitetura de software e estrutura de times. 209 | 210 | Como ponto de partida, recomendamos dividir seu "Event Storming" em subdomínios e [Context Maps](https://speakerdeck.com/mploed/visualizing-sociotechnical-architectures-with-context-maps). 211 | 212 | ![Subdomínios em um EventStorm](/resources/event_storm_sub_domains.png)*Crédito: Alberto Brandolini* 213 | 214 | #### Ferramentas 215 | 216 | - [Modelagem de capacidade de negócios](https://www.slideshare.net/trondhr/from-capabilities-to-services-modelling-for-businessit-alignment-v2) 217 | - [Heurísticas de design](https://www.dddheuristics.com/) 218 | - [EventStorming com subdomínios](https://www.eventstorming.com/) 219 | - [Heurísticas de serviços independente](https://github.com/TeamTopologies/Independent-Service-Heuristics) 220 | - [Visualizando a arquitetura sociotécnica com "Context Mappings"](https://speakerdeck.com/mploed/visualizing-sociotechnical-architectures-with-context-maps) 221 | 222 | #### Quem involver 223 | 224 | - Pessoas que projetam, criam e testam software 225 | - Pessoas que têm conhecimento do domínio 226 | 227 | ### Criar Estratégia 228 | 229 | Mapeie estrategicamente seus subdomínios para identificar os domínios principais: as partes do domínio que têm o maior potencial de diferenciação comercial ou importância estratégica. 230 | 231 | O tempo e os recursos são limitados, portanto, entender em quais partes do domínio se concentrar é fundamental para proporcionar um impacto comercial ideal. 232 | 233 | Ao analisar quais são seus domínios principais, você terá uma ideia melhor de quanta qualidade e rigor são necessários para criar cada parte do seu sistema e poderá tomar decisões altamente embasadas de criar, comprar ou terceirizar. 234 | 235 | Como ponto de partida, recomendamos [Core Domain Charts](https://github.com/ddd-crew/core-domain-charts). 236 | 237 | ![Core Domain Charts](../../resources/core-domain-chart.jpg) 238 | 239 | #### Ferramentas/Recursos 240 | 241 | - [Core Domain Charts](https://github.com/ddd-crew/core-domain-charts) 242 | - [Purpose Alignment Model](https://www.informit.com/articles/article.aspx?p=1384195&seqNum=2) 243 | - [Wardley Mapping](https://learnwardleymapping.com/) 244 | - [Revisitando os fundamentos do Domain-Driven Design](https://vladikk.com/2018/01/26/revisiting-the-basics-of-ddd/) 245 | 246 | #### Quem involver 247 | 248 | - Pessoas que entendem de estratégia de produtos e negócios 249 | - Pessoas que projetam, criam e testam software 250 | - Pessoas que têm conhecimento do domínio 251 | 252 | ### Conectar 253 | 254 | Conecte os subdomínios em uma arquitetura com baixo acoplamento que atenda aos casos de uso de negócios de ponta a ponta. 255 | 256 | É imperativo não apenas decompor um grande domínio em partes, mas também projetar cuidadosamente as interações entre essas partes para minimizar o acoplamento e a complexidade indesejados. É necessário desafiar o projeto inicial aplicando casos de uso concretos para descobrir a complexidade oculta. 257 | 258 | Como ponto de partida, recomendamos [Domain Message Flow Modelling](https://github.com/ddd-crew/domain-message-flow-modelling). 259 | 260 | ![Domain Message Flow Modelling](../../resources/domain-message-flow.jpg) 261 | 262 | #### Ferramentas 263 | 264 | - ["Business Process Model" e "Notation"](https://en.wikipedia.org/wiki/Business_Process_Model_and_Notation) 265 | - ["Domain Message Flow Modelling"](https://github.com/ddd-crew/domain-message-flow-modelling) 266 | - ["Process Modelling EventStorming"](https://www.eventstorming.com/) 267 | - [Diagramas de Sequência](https://en.wikipedia.org/wiki/Sequence_diagram) 268 | 269 | #### Quem involver 270 | 271 | - Pessoas que projetam, criam e testam software 272 | - Pessoas que têm conhecimento do domínio 273 | 274 | ### Organizar 275 | 276 | Organize times autônomos que sejam otimizados para um fluxo rápido e alinhados com os contextos delimitados. 277 | 278 | Os times precisam ser organizados para ter autonomia, metas claras e senso de propósito. Para isso, precisamos levar em conta as restrições organizacionais, de modo que os times se organizem para um fluxo rápido. 279 | 280 | > #### Auto-organização da equipe 281 | > 282 | > A organização dos times não é algo que é feito pelos times, mas eles devem estar envolvidos no processo de definição de seus limites, interações e responsabilidades. 283 | > 284 | > Algumas empresas, como a Red Gate Software, capacitam e confiam em suas equipes para [organizar-se com autonomia](https://medium.com/ingeniouslysimple/how-redgate-ran-its-first-team-self-selection-process-4bfac721ae2). 285 | 286 | Podemos otimizar a forma como as pessoas colaboram umas com as outras se alinharmos as equipes com os limites do contexto. Para dimensionar corretamente as equipes, precisamos levar em conta o talento disponível, a carga cognitiva, a sobrecarga de comunicação e o fator ônibus. 287 | 288 | Como ponto de partida, recomendamos visualizar a arquitetura sociotécnica com o [Context Maps](https://speakerdeck.com/mploed/visualizing-sociotechnical-architectures-with-context-maps). Uma breve visão geral dos padrões mais importantes pode ser encontrada na seção [context-mapping](https://github.com/ddd-crew/context-mapping) GitHub Project. 289 | 290 | ![Context Map](../../resources/context-map-cheat-sheet.png)*Crédito: Michael Plöd* 291 | 292 | #### Ferramentas 293 | 294 | - ["Dynamic Reteaming"](https://leanpub.com/dynamicreteaming) 295 | - ["Pioneers, Settlers & Town Planners"](http://wardleypedia.org/mediawiki/index.php/Pioneers_settlers_town_planners) 296 | - ["Team Topologies"](https://teamtopologies.com/) 297 | - [Visualizando a arquitetura sociotécnica com "Context Maps"](https://speakerdeck.com/mploed/visualizing-sociotechnical-architectures-with-context-maps) 298 | 299 | #### Quem involver 300 | 301 | - Pessoas que projetam, criam e testam software 302 | - Pessoas que têm conhecimento do domínio 303 | - Pessoas que entendem o produto e a estratégia de negócios 304 | 305 | ### Definir 306 | 307 | Definir as funções e responsabilidades de cada ["bounded context"](https://martinfowler.com/bliki/BoundedContext.html). 308 | 309 | Antes de se comprometer com um projeto, tome decisões explícitas sobre as escolhas que podem ter um impacto significativo no projeto geral. Tenha essas conversas logo no início, enquanto ainda é fácil mudar de ideia e explorar modelos alternativos. 310 | 311 | Projete de forma colaborativa e visual, e comece a considerar as limitações técnicas para que você possa descobrir restrições ou oportunidades. 312 | 313 | Como ponto de partida, recomendamos o ["Bounded Context Canvas"](https://github.com/ddd-crew/bounded-context-canvas). 314 | 315 | ![Bounded Context Canvas](resources/bounded-context-canvas-v5.jpg) 316 | 317 | #### Ferramentas 318 | 319 | - ["Bounded Context Canvas"](https://github.com/ddd-crew/bounded-context-canvas) 320 | - [Diagrama de contexto do sistema C4](https://c4model.com/#SystemContextDiagram) 321 | - ["Quality Storming"](https://speakerdeck.com/mploed/quality-storming) 322 | 323 | #### Quem involver 324 | 325 | - Pessoas que projetam, criam e testam software 326 | - Pessoas que têm conhecimento do domínio 327 | - Pessoas que são responsáveis pelo produto 328 | 329 | ### Codificar 330 | 331 | Codifique o modelo de domínio. 332 | 333 | Alinhar o código ao domínio facilita a alteração do código quando o domínio muda. Ao modelar de forma colaborativa o espaço do problema com especialistas, os desenvolvedores têm a chance de aprender sobre o domínio e minimizar os mal-entendidos. 334 | 335 | Como ponto de partida, recomendamos o ["Aggregate Design Canvas"](https://github.com/ddd-crew/aggregate-design-canvas). 336 | 337 | !["Aggregate Design Canvas"](../../resources/aggregate-design-canvas-v1.jpg) 338 | 339 | #### Ferramentas 340 | 341 | - ["Aggregate Design Canvas"](https://github.com/ddd-crew/aggregate-design-canvas) 342 | - ["Diagramas de componentes C4"](https://c4model.com/#ComponentDiagram) 343 | - ["Design-Level EventStorming"](https://www.eventstorming.com/) 344 | - ["Event Modeling"](https://eventmodeling.org/posts/what-is-event-modeling/) 345 | - ["Hexagonal Architecture"](https://en.wikipedia.org/wiki/Hexagonal_architecture_(software)) 346 | - ["Mob Programming"](https://mobprogramming.org/) 347 | - ["Model Exploration Whirlpool"](https://domainlanguage.com/ddd/whirlpool/) 348 | - ["Onion Architecture"](https://jeffreypalermo.com/2008/07/the-onion-architecture-part-1/) 349 | - ["Unified Modelling Language"](https://en.wikipedia.org/wiki/Unified_Modeling_Language) 350 | 351 | #### Quem involver 352 | 353 | - Pessoas que projetam, criam e testam software 354 | 355 | ### Como o "Domain-Driven Design Starter Modelling Process" se relaciona com o processo Whirlpool 356 | 357 | Alguns de vocês devem ter notado algumas semelhanças com o livro de Eric Evans [Whirlpool Process](https://www.domainlanguage.com/ddd/whirlpool/). E, de fato, ambos são guias e não práticas recomendadas rígidas. Eles também são contínuos e iterativos. 358 | Mas o Processo Initial de DDD é mais agrangente do que o processo Whirlpool, pois visa à criação de uma arquitetura sociotécnica. 359 | A figura abaixo mostra uma possível sobreposição entre os dois processos. 360 | 361 | ![WhirlpoolVSStarter](../../resources/ENWhirlpoolVSStarter.jpg) 362 | 363 | Não é preciso dizer que o processo Whirlpool de Eric Evan continua totalmente relevante até hoje e oferece às pessoas percepções e orientações muito valiosas sobre como explorar modelos. 364 | 365 | ## Contribuidores 366 | 367 | Obrigado a todos [contribuidores atuais e futuros](https://github.com/ddd-crew/ddd-starter-modelling-process/graphs/contributors) e às seguintes pessoas que contribuíram para o "Domain-Driven Design Starter Modelling Process": 368 | 369 | - [Ciaran McNulty](https://github.com/ciaranmcnulty) 370 | - [Eduardo da Silva](https://github.com/emgsilva) 371 | - [Gien Verschatse](https://twitter.com/selketjah) 372 | - [James Morcom](https://twitter.com/morcs) 373 | - [Maxime Sanglan-Charlier](https://twitter.com/__MaxS__) 374 | 375 | ## Contribuições e Feedback 376 | 377 | O "Domain-Driven Design Starter Modelling Process" está disponível gratuitamente para seu uso. Além disso, seus comentários e ideias são bem-vindos para aprimorar a técnica ou criar versões alternativas. 378 | 379 | Se tiver dúvidas, você pode nos contactar ou abrir um [Issue](https://github.com/ddd-crew/ddd-starter-modelling-process/issues/new/choose). 380 | 381 | Sinta-se à vontade para também nos enviar pull-requests com seus [estudos de caso](/case-studies). 382 | 383 | [![CC BY 4.0][cc-by-shield]][cc-by] 384 | 385 | ste trabalho está licenciado sob uma licença [Creative Commons Attribution 4.0 International 386 | License][cc-by]. 387 | 388 | [![CC BY 4.0][cc-by-image]][cc-by] 389 | 390 | [cc-by]: http://creativecommons.org/licenses/by/4.0/ 391 | [cc-by-image]: https://i.creativecommons.org/l/by/4.0/88x31.png 392 | [cc-by-shield]: https://img.shields.io/badge/License-CC%20BY%204.0-lightgrey.svg 393 | -------------------------------------------------------------------------------- /translations/pt-br/resources/bounded-context-canvas-v5.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ddd-crew/ddd-starter-modelling-process/7190272f5964c8bce749ddf06367c5afe72c85db/translations/pt-br/resources/bounded-context-canvas-v5.jpg -------------------------------------------------------------------------------- /translations/pt-br/resources/ddd-starter-modeling-circular-pt-br.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ddd-crew/ddd-starter-modelling-process/7190272f5964c8bce749ddf06367c5afe72c85db/translations/pt-br/resources/ddd-starter-modeling-circular-pt-br.jpg -------------------------------------------------------------------------------- /translations/zh-tw/README.md: -------------------------------------------------------------------------------- 1 | # 領域驅動設計 (DDD) 建模流程入門 2 | 3 | 4 | 5 |
6 | 這個流程為你提供逐步指南，以學習並實際應用領域驅動設計 (DDD) 的每個方面 - 從圍繞組織的商業模型到編碼領域模型。 7 | 8 | > This process gives you a step-by-step guide for learning and practically applying each aspect of Domain-Driven Design (DDD) - from orienting around an organisation's business model to coding a domain model. 9 | 10 |
11 | 12 |
13 | 使用此流程將引導你完成使用 DDD 思維設計軟體系統的每個必要步驟，以便你可以專注於你的業務挑戰，而不會同時被學習 DDD 搞得不知所措。 14 | 15 | > Using this process will guide you through each of the essential steps in designing a software system with the DDD mindset, so you can focus on your business challenges and not be overwhelmed by learning DDD at the same time. 16 | 17 |
18 | 19 |
20 | 經過幾次迭代後，你將具備基礎的 DDD 理論和實務經驗，可以更深入瞭解 DDD。然後，你將能夠調整和改進流程，以滿足你在任何情境下的需求。在實際專案中，你通常會在這些步驟之間來回跳躍。 21 | 22 | > Once you have been through a few iterations of the process you will have the foundational DDD theory and practical experience to go deeper into DDD. Then you will be able to adapt and improve the process to suit your needs in any context. On a real project you'll often be jumping back and forth between these steps. 23 | 24 |
25 | 26 | > 這個流程適合初學者，而且它不是你應該標準化為最佳實務的實作步驟，領域驅動設計是一種演進式設計程式，需要對知識和設計的所有方面進行持續迭代。 27 | 28 | 29 | 30 | ![領域驅動設計 (DDD) 建模流程入門](resources/ddd-starter-modelling-process-colored.png) 31 | 32 |
33 | 導覽： 34 | 35 | > __Navigation:__ 36 | 37 |
38 | 39 | - [領域驅動設計 (DDD) 建模流程入門](#領域驅動設計-ddd-建模流程入門) 40 | - [何時使用 DDD 建模流程入門？](#何時使用-ddd-建模流程入門) 41 | - [開始一個 Greenfield 專案](#開始一個-greenfield-專案) 42 | - [開始一個 Brownfield 遷移](#開始一個-brownfield-遷移) 43 | - [展開一項重大工作計劃](#展開一項重大工作計劃) 44 | - [探索你的領域以獲取新的學習機會](#探索你的領域以獲取新的學習機會) 45 | - [評估專案的當前狀態](#評估專案的當前狀態) 46 | - [重新組織團隊](#重新組織團隊) 47 | - [練習或學習 DDD](#練習或學習-ddd) 48 | - [如何調整流程？](#如何調整流程) 49 | - [從協作建模開始](#從協作建模開始) 50 | - [從評估 IT 環境開始](#從評估-it-環境開始) 51 | - [在確認架構和團隊界限之前編寫程式碼](#在確認架構和團隊界限之前編寫程式碼) 52 | - [重複步驟 2（發現）~ 步驟 6（組織）然後再進行步驟 7（定義）](#重複步驟-2發現-步驟-6組織然後再進行步驟-7定義) 53 | - [在設計情境之前組織團隊](#在設計情境之前組織團隊) 54 | - [混合定義與編碼](#混合定義與編碼) 55 | - [流程](#流程) 56 | - [步驟 1: 瞭解 (Understand)](#步驟-1-瞭解-understand) 57 | - [工具](#工具) 58 | - [誰應該參與](#誰應該參與) 59 | - [步驟 2: 探索 (Discover)](#步驟-2-探索-discover) 60 | - [工具](#工具-1) 61 | - [誰應該參與](#誰應該參與-1) 62 | - [步驟 3: 分解 (Decompose)](#步驟-3-分解-decompose) 63 | - [工具](#工具-2) 64 | - [誰應該參與](#誰應該參與-2) 65 | - [步驟 4: 策略 (Strategize)](#步驟-4-策略-strategize) 66 | - [工具/資源](#工具資源) 67 | - [誰應該參與](#誰應該參與-3) 68 | - [步驟 5: 連接 (Connect)](#步驟-5-連接-connect) 69 | - [工具](#工具-3) 70 | - [誰應該參與](#誰應該參與-4) 71 | - [步驟 6: 組織 (Organise)](#步驟-6-組織-organise) 72 | - [工具](#工具-4) 73 | - [誰應該參與](#誰應該參與-5) 74 | - [步驟 7: 定義 (Define)](#步驟-7-定義-define) 75 | - [工具](#工具-5) 76 | - [誰應該參與](#誰應該參與-6) 77 | - [步驟 8: 程式碼 (Code)](#步驟-8-程式碼-code) 78 | - [工具](#工具-6) 79 | - [誰應該參與](#誰應該參與-7) 80 | - [DDD 建模流程入門與 Whirlpool 流程的關聯](#ddd-建模流程入門與-whirlpool-流程的關聯) 81 | - [貢獻者](#貢獻者) 82 | - [貢獻與回饋](#貢獻與回饋) 83 | 84 | 130 | 131 | ## 何時使用 DDD 建模流程入門？ 132 | 133 | 134 |
135 | 如果你是 DDD 的新手，或者只是不確定從哪裡開始，這個過程可以減輕你的認知負擔。它將引導你遵循以下情境，可能還有其他情境： 136 | 137 | > If you're new to DDD or just not sure where to start, this process can reduce your cognitive load. It will guide you through following scenarios, and possibly others: 138 | 139 |
140 | 141 | ### 開始一個 Greenfield 專案 142 | 143 | 144 |
145 | 在開始一個新專案時，你需要考慮的事情可能會多到令人不知所措。重複這個過程一兩次，可以幫助你建立基礎。 146 | 147 | > At the start of a new project the number of things you need to think about can be overwhelming. One or two iterations of this process can help you put the foundations in place. 148 | 149 |
150 | 151 | ### 開始一個 Brownfield 遷移 152 | 153 | 154 |
155 | 在開始現代化你的舊系統之前，此程式的幾次迭代可以幫助你發現建立目標架構願景所需的必要資訊。 156 | 157 | > Before getting to work on modernising your legacy system, a few iterations of this process can help you to uncover essential information needed to create a vision for your target architecture. 158 | 159 |
160 | 161 | ### 展開一項重大工作計劃 162 | 163 | 164 |
165 | 當啟動一項新計劃涉及多個團隊的大量投資時，涵蓋流程中的 8 個步驟至關重要。此流程可以引導你完成前幾次迭代。 166 | 167 | > When starting a new initiative involves a significant investment across many teams, it is essential to cover the 8 steps in the process. This process can guide you through the first few iterations. 168 | 169 |
170 | 171 | ### 探索你的領域以獲取新的學習機會 172 | 173 | 174 |
175 | 軟體開發是一個學習的過程。你可以隨時應用 DDD 建模流程入門來發現新的見解、識別新的機會，或只是在團隊中分享知識。 176 | 177 | > Software development is a learning process. You can apply the DDD Starter Modelling Process at any time to uncover new insights, identify new opportunities, or simply share knowledge around the team. 178 | 179 |
180 | 181 | ### 評估專案的當前狀態 182 | 183 | 184 |
185 | 這個過程可以作為評估你目前的系統與領域和商業模型的契合程度的基礎。 186 | 187 | > This process can be the foundation for assessing how well your current system is aligned to the domain and business model. 188 | 189 |
190 | 191 | ### 重新組織團隊 192 | 193 | 194 |
195 | 鬆散耦合的架構使團隊能夠並行工作而不會受到阻礙。鬆散耦合的架構也必須與領域中的耦合保持一致。此過程將幫助你設計軟體架構，以及與你的領域一致的團隊結構。 196 | 197 | > A loosely-coupled architecture enables teams to work in parallel without being blocked. A loosely-coupled architecture also must be aligned to coupling in the domain. This process will help you to design a software architecture, and a team structure aligned with your domain. 198 | 199 |
200 | 201 | ### 練習或學習 DDD 202 | 203 | 204 |
205 | 這個過程在你剛接觸 DDD 並想練習時非常理想，或者你想教導他人建模領域的不同面向。重要的是要傳達這個線性過程並非實際的過程。這只是一個起點，可以減少認知負擔，直到你對 DDD 有信心為止。 206 | 207 | > This process is ideal when you are new to DDD and want to practice, or you want to teach others the different aspects of modelling a domain. It's important to communicate that this linear process is not a realistic process. It's just a starting point to reduce cognitive load until you are confident with DDD. 208 | 209 |
210 | 211 |
212 | 如果你想親自嘗試，SAP 的同事已建立一個 DDD Kata 來教育團隊，如何在你的團隊中應用 DDD 建模流程。根據一組需求，你可以嘗試 EventStorming、Domain Message Flow、Bounded Context Canvas 和 Aggregate Canvas 如何協同運作，並幫助你驗證你的設計決策。 213 | 214 | > If you want to try it out yourself, colleagues at SAP have created a [DDD Kata](https://github.com/SAP/curated-resources-for-domain-driven-design/blob/main/ddd-kata.md) to educate teams, how to apply the DDD Modelling Process in your team. Based upon a set of requirements, you can try out how EventStorming, Domain Message Flow, Bounded Context Canvas and Aggregate Canvas work together and help you to validate your design decisions. 215 | 216 |
217 | 218 | ## 如何調整流程？ 219 | 220 | 221 |
222 | 這個過程可以透過多種方式進行自訂。在一個真實的專案中，你將根據獲得或需要獲得的新見解在所有 8 個步驟之間進行切換。 223 | 224 | > This process can be customised in many ways. On a real project, you'll be switching between all 8 steps based on the new insights you gain or need to gain. 225 | 226 |
227 | 228 |
229 | 以下是一些決定何時更改順序或在步驟之間切換的原因。 230 | 231 | > Below are a few reasons for deciding when to change the order or switch between steps. 232 | 233 |
234 | 235 | ### 從協作建模開始 236 | 237 | 238 |
239 | 如果你想讓整個團隊立即展開協作，建模他們熟悉的領域可能比談論他們不太熟悉的商業模型和策略更為舒適。 240 | 241 | > If you want to get your whole team collaborating immediately, modelling the domain which they are familiar with might be more comfortable than talking about business models and strategy which they are less comfortable with. 242 | 243 |
244 | 245 | ### 從評估 IT 環境開始 246 | 247 | 248 |
249 | 在展望業務願景並深入領域之前，最好先視覺化現有架構。從步驟 5 開始，並繪製你的策略組合，以瞭解你將面臨的主要限制。 250 | 251 | > Before looking forward to the business vision and going deep into the domain, it might be better to visualise the existing architecture first. Start with step 5 and map out your strategic portfolio to see what the major constraints you will face are. 252 | 253 |
254 | 255 | ### 在確認架構和團隊界限之前編寫程式碼 256 | 257 | 258 |
259 | 在某些專案中，提早開始撰寫程式碼是有道理的。也許你需要交付 MVP，或者該領域非常複雜，以至於在考慮架構之前，必須在程式碼中建立模型。 260 | 261 | > On some projects it makes sense to start by writing code sooner. Perhaps you need to deliver an MVP or the domain is so complex that creating a model in code is necessary before you can consider the architecture. 262 | 263 |
264 | 265 | ### 重複步驟 2（發現）~ 步驟 6（組織）然後再進行步驟 7（定義） 266 | 267 | 268 |
269 | 在深入瞭解個別邊界上下文的定義之前，建模多個領域並尋找將系統分解為子領域和團隊的不同方法可能是有益的。 270 | 271 | > Before you dive into the definition of individual bounded contexts, it may be beneficial to model the domain multiple times and look for different ways to decompose your system into sub-domains and teams. 272 | 273 |
274 | 275 | ### 在設計情境之前組織團隊 276 | 277 | 278 |
279 | 對於許多專案而言，我們需要考慮組織限制。如果是這樣，你應該考慮在設計永遠無法實施的架構之前，識別可能的團隊結構。 280 | 281 | > For a great deal of projects there are organisational constraints that we need to take into account. If this is the case, you should consider identifying possible team structures before designing architectures that you will never be able to implement. 282 | 283 |
284 | 285 | ### 混合定義與編碼 286 | 287 | 288 |
289 | 步驟 7（定義）和步驟 8（程式碼）可以同時進行。當你編寫 Bounded Context 的程式碼時，可能會發生這種情況，而你從編寫程式碼中獲得的見解會讓你更改高階設計。 290 | 291 | > Steps 7 (Define) and 8 (Code) can occur concurrently. This may happen when you are coding a bounded context, and the insights you get from writing code make you change the high-level design. 292 | 293 |
294 | 295 | ## 流程 296 | 297 | 298 |
299 | 建模過程由以下介紹的 8 個步驟組成。 300 | 301 | > The modelling process is composed of 8 steps which are introduced below. 302 | 303 |
304 | 305 |
306 | 一個好的演講概述了在設計社會技術架構的典型階段中該過程的內容，是 Eduardo da Silva 的「社會技術架構：共同設計技術和組織架構以最大化影響」。Eduardo 將該過程的活動及其 8 個步驟分組為四個不同的階段，即： 307 | 308 | > A good talk that gives an overview of the process in the context of typical phases of designing sociotechnical architectures is ["Sociotechnical Architecture: co-designing technical & organizational architecture to maximize impact"](https://www.youtube.com/watch?v=ekMPm78KFj0&feature=youtu.be&t=1820) by [Eduardo da Silva](https://twitter.com/emgsilva). Eduardo groups the activities of the process and its 8 steps in [four distinct phases](https://speakerdeck.com/emgsilva/intro-to-sociotechnical-architecture-co-designing-technical-and-organizational-architecture-to-maximize-impact?slide=31), namely: 309 | 310 |
311 | 312 | 1. 對齊與理解 (Align & Understand) 313 | 2. 戰略架構 (Strategic Architecture) 314 | 3. 戰略與組織設計 (Strategy & Org Design) 315 | 4. 戰術架構 (Tactical Architecture) 316 | 317 | ### 步驟 1: 瞭解 (Understand) 318 | 319 |
320 | 將我們的重點與組織的商業模型、其使用者的需求，以及其短期、中期和長期目標保持一致。 321 | 322 | > Align our focus with the organisation's business model, the needs of its users, and its short, medium, and long-term goals. 323 | 324 |
325 | 326 |
327 | 我們在架構、程式碼或組織方面所做的每個決定，都會對業務和使用者造成影響。為了最有效地設計、建構和發展軟體系統，我們的決定需要創造最佳的業務影響，而這只有在我們與業務目標保持一致，並支援使用者當前和潛在的未來需求時才能實現。 328 | 329 | > Every decision we take regarding the architecture, the code, or the organisation has business and user consequences. In order to design, build, and evolve software systems most effectively, our decisions need to create the optimal business impact, which can only be achieved if we are aligned to the business goals, as well as supporting the users current and potential future needs. 330 | 331 |
332 | 333 |
334 | 不良的架構和/或邊界設計可能會產生負面影響，甚至使實現這些目標變得不可能。 335 | 336 | > Badly designed architecture and/or boundaries can have a negative impact or even make it impossible to achieve these goals. 337 | 338 |
339 | 340 |
341 | 作為起點，我們推薦 The Business Model Canvas 作為商業觀點，使用者故事地圖作為理解使用者觀點。 342 | 343 | > As a starting point, we recommend [The Business Model Canvas](https://www.strategyzer.com/canvas/business-model-canvas) for the business perspective, [User Story Mapping](https://www.jpattonassociates.com/user-story-mapping/) for understanding the user vantage point. 344 | 345 |
346 | 347 | ![The Business Model Canvas](resources/business-model-canvas.png) 348 | 349 | #### 工具 350 | 351 | 352 | - [影響力對應 (Impact Mapping)](https://www.impactmapping.org/) 353 | - [商業模型畫布 (The Business Model Canvas)](https://www.strategyzer.com/canvas/business-model-canvas) 354 | - [產品策略畫布 (The Product Strategy Canvas)](https://melissaperri.com/blog/2016/07/14/what-is-good-product-strategy) 355 | - [沃德利對應 (Wardley Mapping)](https://learnwardleymapping.com/) 356 | - [使用者故事對應 (User Story Mapping)](https://www.jpattonassociates.com/user-story-mapping/) 357 | 358 | #### 誰應該參與 359 | 360 | 361 | - 設計、建構、測試軟體的人員 (People who design, build, test software) 362 | - 具有領域知識的人員 (People who have domain knowledge) 363 | - 瞭解產品和業務策略的人員 (People who understand the product and business strategy) 364 | - 真正的最終使用者，而不僅是組織中的代表 (Real end users, not only their representatives in your organisation) 365 | 366 | ### 步驟 2: 探索 (Discover) 367 | 368 |
369 | 以視覺化和協作方式探索領域。 370 | 371 | > Discover the domain visually and collaboratively. 372 | 373 |
374 | 375 |
376 | 這是 DDD 最關鍵的方面。你不能跳過探索。如果你的整個團隊對領域沒有建立良好的理解，所有軟體決策都會被誤導。 377 | 378 | > This is the most crucial aspect of DDD. You cannot skip discovery. If your whole team doesn't build up a good understanding of the domain, all software decisions will be misguided. 379 | 380 |
381 | 382 |
383 | 透過整個團隊傳播領域知識將會創造出共同的理解。它使開發人員能夠建立與領域一致的軟體系統，該系統可以更靈活地納入未來的業務變化。 384 | 385 | > Spreading domain knowledge through the whole team will create a shared understanding. It enables the developers to build a software system aligned to the domain which can be more flexible to incorporate future business changes. 386 | 387 |
388 | 389 |
390 | 確保領域知識在整個團隊中傳播，使成員能夠貢獻想法來改進產品。 391 | 392 | > Ensuring that domain knowledge is spread across the whole team enables its members to contribute with ideas for improving the product. 393 | 394 |
395 | 396 | > #### 探索是持續不斷的 (Discovery is Continuous) 397 | > 398 | > 團隊成功實踐 DDD 的關鍵在於經常練習探索技巧。關於領域總是有更多可以學習的地方。 399 | > 400 | > 在首次嘗試探索時，一位經驗豐富的引導者，例如熟悉 EventStorming 等技巧的人，可以幫助團隊看到探索的真正好處，而不僅僅是表 面上的好處。 401 | > 402 | > 我們強烈建議您檢視 [視覺協作工具](https://leanpub.com/visualcollaborationtools) (Visual Collaboration Tools)。 403 | 404 | 411 | 412 |
413 | 作為起點，我們推薦 事件風暴 (EventStorming)。 414 | 415 | > As a starting point, we recommend [EventStorming](https://www.eventstorming.com/). 416 | 417 |
418 | 419 | ![EventStorming](resources/event_storming.jpeg) 420 | 421 | #### 工具 422 | 423 | 424 | - [領域故事 (Domain Storytelling)](https://domainstorytelling.org/) 425 | - [範例對應 (Example Mapping)](https://cucumber.io/blog/bdd/example-mapping-introduction/) 426 | - [事件風暴 (EventStorming)](https://www.eventstorming.com/) 427 | - [使用者旅程對應 (User Journey Mapping)](https://boagworld.com/audio/customer-journey-mapping/) 428 | - [使用者故事對應 (User Story Mapping)](https://www.jpattonassociates.com/user-story-mapping/) 429 | 430 | #### 誰應該參與 431 | 432 | 433 | - 設計、建構、測試軟體的人員 (People who design, build, test software) 434 | - 具有領域知識的人員 (People who have domain knowledge) 435 | - 瞭解產品和業務策略的人員 (People who understand product and business strategy) 436 | - 瞭解客戶需求和問題的人員 (People who understand the customers' needs and problems) 437 | - 真正的最終使用者 (Real end users) 438 | 439 | ### 步驟 3: 分解 (Decompose) 440 | 441 |
442 | 將領域分解成子領域 - 領域的鬆散耦合部分。 443 | 444 | > Decompose the domain into sub-domains - loosely-coupled parts of the domain. 445 | 446 |
447 | 448 |
449 | 我們將大型問題領域分解成子領域，原因有幾個： 450 | 451 | > We decompose a large problem domain into sub-domains for a few key reasons: 452 | 453 |
454 | 455 | - 降低認知負擔，以便我們可以獨立地推論領域的各個部分，\ 456 | reduced cognitive load, so that we can reason about parts of the domain independently, 457 | - 給予開發團隊自主權，以便他們可以處理解決方案的各個部分，\ 458 | give development teams autonomy, so that they can work on separate parts of the solution, 459 | - 識別領域中的鬆散耦合和高內聚，這些會轉移到我們的軟體架構和團隊結構中。\ 460 | identifying loose-coupling and high-cohesion in the domain which carries over to our software architecture and team structure. 461 | 462 |
463 | 作為起點，我們建議將你的**事件風暴**劃分為子領域(sub-domains)和 Context Maps。 464 | 465 | > As a starting point, we recommend carving up your event storm into sub-domains and [Context Maps](https://speakerdeck.com/mploed/visualizing-sociotechnical-architectures-with-context-maps). 466 | 467 |
468 | 469 | ![活動風暴中的子領域 (Sub-domains on an EventStorm)](resources/event_storm_sub_domains.png) *Credit: Alberto Brandolini* 470 | 471 | #### 工具 472 | 473 | 474 | - [商業能力建模 (Business Capability Modelling)](https://www.slideshare.net/trondhr/from-capabilities-to-services-modelling-for-businessit-alignment-v2) 475 | - [設計啟發法 (Design Heuristics)](https://www.dddheuristics.com/) 476 | - [子領域的事件風暴 (EventStorming with sub-domains)](https://www.eventstorming.com/) 477 | - [獨立服務啟發法 (Independent Service Heuristics)](https://github.com/TeamTopologies/Independent-Service-Heuristics) 478 | - [使用情境圖視覺化社會技術架構 (Visualising Sociotechnical Architecture with Context Maps)](https://speakerdeck.com/mploed/visualizing-sociotechnical-architectures-with-context-maps) 479 | 480 | #### 誰應該參與 481 | 482 | 483 | - 設計、建構、測試軟體的人員 (People who design, build, test software) 484 | - 具有領域知識的人員 (People who have domain knowledge) 485 | 486 | ### 步驟 4: 策略 (Strategize) 487 | 488 |
489 | 策略性地繪製你的子領域，以識別核心領域：領域中具有最大業務差異化或戰略意義的部份。 490 | 491 | > Strategically map out your sub-domains to identify core domains: the parts of the domain which have the greatest potential for business differentiation or strategic significance. 492 | 493 |
494 | 495 |
496 | 時間和資源有限，因此瞭解應專注於領域的哪些部分對於提供最佳業務影響至關重要。 497 | 498 | > Time and resources are limited, so understanding which parts of the domain to focus on is critical to delivering optimal business impact. 499 | 500 |
501 | 502 |
503 | 透過分析你的核心領域，你將更清楚瞭解建構系統各部分所需的品質和嚴謹程度，並且能夠做出高素質的建構、購買或外包決策。 504 | 505 | > By analysing what your core domains are, you will have a better idea of how much quality and rigour is required to build each part of your system, and you'll be able to make highly-educated build vs buy vs outsource decisions. 506 | 507 |
508 | 509 |
510 | 作為起點，我們推薦 核心領域圖表。 511 | 512 | > As a starting point, we recommend [Core Domain Charts](https://github.com/ddd-crew/core-domain-charts). 513 | 514 |
515 | 516 | ![核心領域圖表 (Core Domain Charts)](resources/core-domain-chart.jpg) 517 | 518 | #### 工具/資源 519 | 520 | 521 | - [核心領域圖表 (Core Domain Charts)](https://github.com/ddd-crew/core-domain-charts) 522 | - [目的對齊模型 (Purpose Alignment Model)](https://www.informit.com/articles/article.aspx?p=1384195&seqNum=2) 523 | - [沃德利對映 (Wardley Mapping)](https://learnwardleymapping.com/) 524 | - [重溫領域驅動設計的基本知識 (Revisiting the Basics of Domain-Driven Design)](https://vladikk.com/2018/01/26/revisiting-the-basics-of-ddd/) 525 | 526 | #### 誰應該參與 527 | 528 | 529 | - 瞭解產品和業務策略的人員 (People who understand product and business strategy) 530 | - 設計、建構、測試軟體的人員 (People who design, build, test software) 531 | - 具有領域知識的人員 (People who have domain knowledge) 532 | 533 | ### 步驟 5: 連接 (Connect) 534 | 535 |
536 | 將子領域連線成一個鬆散耦合的架構，以滿足端到端的業務使用案例。 537 | 538 | > Connect the sub-domains into a loosely-coupled architecture which fulfills end-to-end business use-cases. 539 | 540 |
541 | 542 |
543 | 不僅要將大型領域分解成各個部分，還必須仔細設計各部分之間的互動，以將不必要的耦合和複雜性降到最低。必須透過套用具體使用案例來挑戰初始設計，以揭露隱藏的複雜性。 544 | 545 | > It is imperative to not only decompose a large domain into parts but to also carefully design the interactions between those parts to minimise unwanted coupling and complexity. It is necessary to challenge the initial design by applying concrete use-cases to uncover hidden complexity. 546 | 547 |
548 | 549 |
550 | 作為起點，我們推薦 Domain Message Flow Modelling。 551 | 552 | > As a starting point, we recommend [Domain Message Flow Modelling](https://github.com/ddd-crew/domain-message-flow-modelling). 553 | 554 |
555 | 556 | 557 | ![領域訊息流程建模 (Domain Message Flow Modelling)](resources/domain-message-flow.jpg) 558 | 559 | #### 工具 560 | 561 | 562 | - [商業流程模型與標記法 (Business Process Model and Notation)](https://zh.wikipedia.org/wiki/%E5%95%86%E6%A5%AD%E6%B5%81%E7%A8%8B%E6%A8%A1%E5%9E%8B%E8%88%87%E6%A8%99%E8%A8%98%E6%B3%95) 563 | - [領域訊息流建模 (Domain Message Flow Modelling)](https://github.com/ddd-crew/domain-message-flow-modelling) 564 | - [流程建模事件風暴(Process Modelling EventStorming)](https://www.eventstorming.com/) 565 | - [順序圖 (Sequence Diagrams)](https://zh.wikipedia.org/wiki/%E9%A0%86%E5%BA%8F%E5%9C%96) 566 | 567 | #### 誰應該參與 568 | 569 | 570 | - 設計、建構、測試軟體的人員 (People who design, build, test software) 571 | - 具有領域知識的人員 (People who have domain knowledge) 572 | 573 | ### 步驟 6: 組織 (Organise) 574 | 575 |
576 | 組織自主團隊，以最佳化快速流程並與情境界限保持一致。 577 | 578 | > Organise autonomous teams that are optimised for fast flow and aligned with context boundaries. 579 | 580 |
581 | 582 |
583 | 團隊需要組織起來，以擁有自主權、明確的目標和目的感。為了做到這一點，我們需要考慮組織約束，以便團隊組織起來以快速流動。 584 | 585 | > Teams need to be organised to have autonomy, clear goals and sense of purpose. In order to do that we need to take into account organisational constraints, so that teams organise themselves for fast flow. 586 | 587 |
588 | 589 | > #### 團隊自我組織 (Team Self-organisation) 590 | > 591 | > 組織並非對團隊所做的事情，而是團隊應該參與定義其界限、互動和責任的過程。\ 592 | > Organisation is not something that is done to teams, rather teams should be involved in the process of defining their boundaries, interactions, and responsibilities. 593 | > 594 | > 有些公司像 Red Gate Software 授權並信任他們的團隊來 [完全組織他們自己](https://medium.com/ingeniouslysimple/how-redgate-ran-its-first-team-self-selection-process-4bfac721ae2)。\ 595 | > Some companies like Red Gate Software empower and trust their teams to [fully organise themselves](https://medium.com/ingeniouslysimple/how-redgate-ran-its-first-team-self-selection-process-4bfac721ae2). 596 | 597 |
598 | 如果我們將團隊與情境界線結合，我們可以最佳化人們彼此合作的方式。為了調整團隊規模，我們需要考慮可用人才、認知負擔、溝通成本和巴士因子。 599 | 600 | > We can optimise how people collaborate with each other if we align teams with context boundaries. In order to right-size the teams we need to take into account available talent, cognitive load, communication overhead, and bus factor. 601 | 602 |
603 | 604 |
605 | 作為起點，我們建議使用 Context Maps 視覺化社會技術架構。可以在 context-mapping GitHub 專案中找到最重要的模式的簡要概述。 606 | 607 | > As a starting point, we recommend visualising sociotechnical architecture with the [Context Maps](https://speakerdeck.com/mploed/visualizing-sociotechnical-architectures-with-context-maps). A brief overview of the most important patterns can be found under the [context-mapping](https://github.com/ddd-crew/context-mapping) GitHub Project. 608 | 609 |
610 | 611 | ![Context Map](resources/context-map-cheat-sheet.png)*Credit: Michael Plöd* 612 | 613 | #### 工具 614 | 615 | 616 | - [動態團隊 (Dynamic Reteaming)](https://leanpub.com/dynamicreteaming) 617 | - [先鋒、定居者與城鎮規劃師 (Pioneers, Settlers & Town Planners)](http://wardleypedia.org/mediawiki/index.php/Pioneers_settlers_town_planners) 618 | - [團隊拓撲 (Team Topologies)](https://teamtopologies.com/) 619 | - [使用情境圖視覺化社會技術架構 (Visualising Sociotechnical Architecture with Context Maps)](https://speakerdeck.com/mploed/visualizing-sociotechnical-architectures-with-context-maps) 620 | 621 | #### 誰應該參與 622 | 623 | 624 | - 設計、建構、測試軟體的人員 (People who design, build, test software) 625 | - 具有領域知識的人員 (People who have domain knowledge) 626 | - 瞭解產品和業務策略的人員 (People who understand the product and business strategy) 627 | 628 | ### 步驟 7: 定義 (Define) 629 | 630 |
631 | 定義每個 限界上下文 的角色和責任。 632 | 633 | > Define the roles and responsibilities of each [bounded context](https://martinfowler.com/bliki/BoundedContext.html). 634 | 635 |
636 | 637 |
638 | 在確定設計之前，請明確決定可能對整體設計產生重大影響的選擇。在仍然容易改變主意和探索替代模型的早期階段進行這些對話。 639 | 640 | > Before committing to a design, make explicit decisions about the choices which can have a significant impact on the overall design. Have these conversations early while it is still easy to change your mind and explore alternative models. 641 | 642 |
643 | 644 |
645 | 協作和視覺化設計，並開始考慮技術限制，以便你可以發現約束或機會。 646 | 647 | > Design collaboratively and visually, and start to consider the technical limitations so that you can uncover constraints or opportunities. 648 | 649 |
650 | 651 |
652 | 作為起點，我們推薦 Bounded Context Canvas。 653 | 654 | > As a starting point, we recommend the [Bounded Context Canvas](https://github.com/ddd-crew/bounded-context-canvas). 655 | 656 |
657 | 658 | ![Bounded Context Canvas](resources/bounded-context-canvas-v5.jpg) 659 | 660 | #### 工具 661 | 662 | 663 | - [Bounded Context Canvas](https://github.com/ddd-crew/bounded-context-canvas) 664 | - [C4 System Context Diagram](https://c4model.com/#SystemContextDiagram) 665 | - [品質風暴 (Quality Storming)](https://speakerdeck.com/mploed/quality-storming) 666 | 667 | #### 誰應該參與 668 | 669 | 670 | - 設計、建構、測試軟體的人員 (People who design, build, test software) 671 | - 具有領域知識的人員 (People who have domain knowledge) 672 | - 負責產品的人員 (People who are responsible for the product) 673 | 674 | ### 步驟 8: 程式碼 (Code) 675 | 676 |
677 | 編碼領域模型。 678 | 679 | > Code the domain model. 680 | 681 |
682 | 683 |
684 | 將程式碼與領域對齊，讓程式碼在領域變更時更容易變更。透過與專家合作建模問題空間，開發人員有機會瞭解領域並減少誤解。 685 | 686 | > Aligning the code to the domain makes it easier to change the code when the domain changes. By collaboratively modelling the problem space with experts, the developers have a chance to learn about the domain and minimise misunderstandings. 687 | 688 |
689 | 690 |
691 | 作為起點，我們推薦 Aggregate Design Canvas。 692 | 693 | > As a starting point, we recommend the [Aggregate Design Canvas](https://github.com/ddd-crew/aggregate-design-canvas). 694 | 695 |
696 | 697 | ![聚合設計畫布 (Aggregate Design Canvas)](resources/aggregate-design-canvas-v1.jpg) 698 | 699 | #### 工具 700 | 701 | 702 | - [聚合設計畫布 (Aggregate Design Canvas)](https://github.com/ddd-crew/aggregate-design-canvas) 703 | - [C4 元件圖 (C4 Component Diagrams)](https://c4model.com/#ComponentDiagram) 704 | - [設計層級事件風暴 (Design-Level EventStorming)](https://www.eventstorming.com/) 705 | - [事件建模 (Event Modeling)](https://eventmodeling.org/posts/what-is-event-modeling/) 706 | - [六角形架構 (Hexagonal Architecture)](https://en.wikipedia.org/wiki/Hexagonal_architecture_(software)) 707 | - [暴民程式設計 (Mob Programming)](https://mobprogramming.org/) 708 | - [模型探索漩渦 (Model Exploration Whirlpool)](https://domainlanguage.com/ddd/whirlpool/) 709 | - [洋蔥架構 (Onion Architecture)](https://jeffreypalermo.com/2008/07/the-onion-architecture-part-1/) 710 | - [統一建模語言 (Unified Modelling Language)](https://en.wikipedia.org/wiki/Unified_Modeling_Language) 711 | 712 | #### 誰應該參與 713 | 714 | 715 | - 設計、建構、測試軟體的人員 (People who design, build, test software) 716 | 717 | ### DDD 建模流程入門與 Whirlpool 流程的關聯 718 | 719 | 720 |
721 | 你們當中有些人可能已經注意到與 Eric Evans 的 Whirlpool Process 有些相似之處。事實上，兩者都是指南，而不是僵化的最佳實踐。它們也都是連續且迭代的。 722 | 但 DDD 建模流程入門涵蓋的範圍比 Whirlpool 流程更廣，目標是建立社會技術架構。 723 | 724 | > Some of you might have noticed some similarities with Eric Evans' [Whirlpool Process](https://www.domainlanguage.com/ddd/whirlpool/). And indeed, both are guides and not rigid best-practices. They're also both continuous and iterative. 725 | But the DDD Starter Modelling Process covers more than the Whirlpool process by aiming at building a socio-technical architecture. 726 | 727 |
728 | 729 |
730 | 下圖顯示了這兩個流程之間可能的重疊。 731 | 732 | > The picture below shows a possible overlap between the two processes. 733 | 734 |
735 | 736 | ![WhirlpoolVSStarter](resources/ENWhirlpoolVSStarter.jpg) 737 | 738 |
739 | 不用說，Eric Evan 的 Whirlpool 流程在今天仍然完全相關，並為人們提供了探索模型的極具價值的見解和指導。 740 | 741 | > Needless to say that Eric Evan's Whirlpool process remains totally relevant today and gives people highly valuable insights and guidance on how to explore models. 742 | 743 |
744 | 745 | ## 貢獻者 746 | 747 | 748 |
749 | 感謝所有現有和未來的貢獻者以及以下個人，他們都對 DDD 建模流程入門做出了貢獻： 750 | 751 | > Thanks to all [existing and future contributors](https://github.com/ddd-crew/ddd-starter-modelling-process/graphs/contributors) and to the following individuals who have all contributed to the DDD Starter Modelling Process: 752 | 753 |
754 | 755 | - [Ciaran McNulty](https://github.com/ciaranmcnulty) 756 | - [Eduardo da Silva](https://github.com/emgsilva) 757 | - [Gien Verschatse](https://twitter.com/selketjah) 758 | - [James Morcom](https://twitter.com/morcs) 759 | - [Maxime Sanglan-Charlier](https://twitter.com/__MaxS__) 760 | 761 | ## 貢獻與回饋 762 | 763 | 764 |
765 | 領域驅動設計建模流程入門可供你免費使用。此外，歡迎你提供意見和想法，以改進技術或建立其他版本。 766 | 767 | > The Domain-Driven Design Starter Modelling Process is freely available for you to use. In addition, your feedback and ideas are welcome to improve the technique or to create alternative versions. 768 | 769 |
770 | 771 | 如果你有問題，可以 ping 我們或開啟 [Issue](https://github.com/ddd-crew/ddd-starter-modelling-process/issues/new/choose)。 772 | 773 | 歡迎你將你的 [案例研究](/case-studies) 發 Pull Requests 給我們。 774 | 775 | [![CC BY 4.0][cc-by-shield]][cc-by] 776 | 777 | 本作品採用 [創用 CC 姓名標示 4.0 國際授權條款][cc-by] 授權。 778 | 779 | [![CC BY 4.0][cc-by-image]][cc-by] 780 | 781 | [cc-by]: http://creativecommons.org/licenses/by/4.0/ 782 | [cc-by-image]: https://i.creativecommons.org/l/by/4.0/88x31.png 783 | [cc-by-shield]: https://img.shields.io/badge/License-CC%20BY%204.0-lightgrey.svg 784 | -------------------------------------------------------------------------------- /translations/zh-tw/resources/ENWhirlpoolVSStarter.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ddd-crew/ddd-starter-modelling-process/7190272f5964c8bce749ddf06367c5afe72c85db/translations/zh-tw/resources/ENWhirlpoolVSStarter.jpg -------------------------------------------------------------------------------- /translations/zh-tw/resources/aggregate-design-canvas-v1.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ddd-crew/ddd-starter-modelling-process/7190272f5964c8bce749ddf06367c5afe72c85db/translations/zh-tw/resources/aggregate-design-canvas-v1.jpg -------------------------------------------------------------------------------- /translations/zh-tw/resources/bounded-context-canvas-v3.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ddd-crew/ddd-starter-modelling-process/7190272f5964c8bce749ddf06367c5afe72c85db/translations/zh-tw/resources/bounded-context-canvas-v3.jpeg -------------------------------------------------------------------------------- /translations/zh-tw/resources/bounded-context-canvas-v4.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ddd-crew/ddd-starter-modelling-process/7190272f5964c8bce749ddf06367c5afe72c85db/translations/zh-tw/resources/bounded-context-canvas-v4.jpeg -------------------------------------------------------------------------------- /translations/zh-tw/resources/bounded-context-canvas-v5.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ddd-crew/ddd-starter-modelling-process/7190272f5964c8bce749ddf06367c5afe72c85db/translations/zh-tw/resources/bounded-context-canvas-v5.jpg -------------------------------------------------------------------------------- /translations/zh-tw/resources/business-model-canvas.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ddd-crew/ddd-starter-modelling-process/7190272f5964c8bce749ddf06367c5afe72c85db/translations/zh-tw/resources/business-model-canvas.png -------------------------------------------------------------------------------- /translations/zh-tw/resources/context-map-cheat-sheet.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ddd-crew/ddd-starter-modelling-process/7190272f5964c8bce749ddf06367c5afe72c85db/translations/zh-tw/resources/context-map-cheat-sheet.png -------------------------------------------------------------------------------- /translations/zh-tw/resources/context-map.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ddd-crew/ddd-starter-modelling-process/7190272f5964c8bce749ddf06367c5afe72c85db/translations/zh-tw/resources/context-map.jpg -------------------------------------------------------------------------------- /translations/zh-tw/resources/core-domain-chart.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ddd-crew/ddd-starter-modelling-process/7190272f5964c8bce749ddf06367c5afe72c85db/translations/zh-tw/resources/core-domain-chart.jpg -------------------------------------------------------------------------------- /translations/zh-tw/resources/ddd-starter-modelling-process-colored.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ddd-crew/ddd-starter-modelling-process/7190272f5964c8bce749ddf06367c5afe72c85db/translations/zh-tw/resources/ddd-starter-modelling-process-colored.png -------------------------------------------------------------------------------- /translations/zh-tw/resources/ddd-starter-modelling-process.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ddd-crew/ddd-starter-modelling-process/7190272f5964c8bce749ddf06367c5afe72c85db/translations/zh-tw/resources/ddd-starter-modelling-process.jpg -------------------------------------------------------------------------------- /translations/zh-tw/resources/domain-message-flow.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ddd-crew/ddd-starter-modelling-process/7190272f5964c8bce749ddf06367c5afe72c85db/translations/zh-tw/resources/domain-message-flow.jpg -------------------------------------------------------------------------------- /translations/zh-tw/resources/event_storm_sub_domains.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ddd-crew/ddd-starter-modelling-process/7190272f5964c8bce749ddf06367c5afe72c85db/translations/zh-tw/resources/event_storm_sub_domains.png -------------------------------------------------------------------------------- /translations/zh-tw/resources/event_storming.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ddd-crew/ddd-starter-modelling-process/7190272f5964c8bce749ddf06367c5afe72c85db/translations/zh-tw/resources/event_storming.jpeg --------------------------------------------------------------------------------