Keeping architectures relevant
•Télécharger en tant que PPTX, PDF•
2 j'aime•557 vues
May IASA Denver presentation on DDD and Emergent Architecture
Recommandé
Recommandé
Contenu connexe
En vedette
En vedette (20)
Similaire à Keeping architectures relevant
Similaire à Keeping architectures relevant (20)
Plus de Brandon Satrom
Dernier
Dernier (20)
Keeping architectures relevant
- 1. Keeping Architectures Relevant Using Domain-Driven Design and Emergent Architecture Paul Rayner Brandon Satrom AGILITY. CRAFT. ARCHITECTURE.
- 3. And the Architect Returns with the System Design…
- 5. Context
- 7. Domain-Driven Design (DDD) is: a set of driving principles a pattern language for strategic design and architecture.* * not an architecture framework
- 10. Context Mapping
- 11. Distillation Ol’ Core Domain Whiskey
- 12. Principle: Establish Context, Achieve Focus
- 13. Communication
- 14. CommunicationvsJargon Translate Refine Agree
- 15. Every misunderstanding is a bug…
- 16. A New Shared Language Within a context…
- 18. Collaboration
- 20. Agile Testing Matrix Business Facing Storytesting (aka BDD/ATTD) Exploratory Testing Regression Testing Usability Testing Critique the Product Support the Team Q2 Q3 Unit Testing (TDD) Component Testing Integration Testing Performance Reliability Scalability … Q1 Q4 Technology Facing From Agile Testing - Janet Gregory and Lisa Crispin
- 21. Storytesting as hands-on design…
- 23. “ Final source code is the real software design — Jack Reeves ”
- 24. Don’t Coddle…
- 25. Principle: Don’t Coddle, Encapsulate
- 26. Connection
- 29. More here…
- 33. Principle: Simplify to Amplify
- 34. Architecture is a Shared Hallucination
- 35. “ A need to tell and hear stories is essential to the species... the sound of story is the dominant sound of our lives… — Reynolds Price ”
- 36. Principle: Architect a Story…
- 37. Keeping Architectures Relevant Establish context, achieve focus Don’t translate, advocate Don’t coddle, encapsulate Simplify to amplify Architect a story
- 38. Thank You… Paul Rayner Brandon Satrom bsatrom@gmail.com www.userinexperience.com paul@virtual-genius.com www.virtual-genius.com See our article in the March edition… http://bit.ly/ddd_arch_journal
Notes de l'éditeur
- Paul …and not an enterprise data model. Example from conversation with Doug
- http://www.infoq.com/articles/ddd-contextmappinghttp://www.methodsandtools.com/archive/archive.php?id=97
- http://www.infoq.com/articles/ddd-contextmappinghttp://www.methodsandtools.com/archive/archive.php?id=97
- Paul. Refinement Distill as deeper insights into the domain become apparent Architect help articulate the value of core domain distillation to stakeholders Bounded contexts A single, "Enterprise" Model is a bad idea Bounded contexts and a context map Needs to be flexible & change-absorbent without being too prescriptive
- BrandonCreating a new, ubiquitous takes a time commitment and leadership. An architect, typically the translator, is a perfect candidate for stepping into being an advocate for a ubiquitous language.A new language is great, and speaking that language creates understanding? But how to we document that understanding?
- Brandon- Communication and Jargon. Communication is the art of using language to convey meaning consistently and clearly. The goal of communication is shared understanding through unambiguous meaning.- Jargon, a style of communication, is the practice of using certain words and phrases in a way that assumes known context, and thus, can serve as a shortcut in communication. When both parties have a shared understanding of the terminology in play, jargon serves as a valuable shortcut for individuals short on time.Translation results in confusion that propagates into the softwareEvery misunderstanding is a bug in the systemWho is this translator most of the time? The architect
- BrandonTypically, we feel like we have to pick one vocabulary over the other. But each have their problems:Biz-dominated domain is relevant, but inaccurateTech-dominated domain is accurate and precise, but mostly irrelevantWe gain benefit by favoring both and creating a NEW language that takes elements of both and brings in new ideas
- BrandonCreating a new, ubiquitous takes a time commitment and leadership. An architect, typically the translator, is a perfect candidate for stepping into being an advocate for a ubiquitous language.A new language is great, and speaking that language creates understanding? But how to we document that understanding?
- The 4 intrinsic rewardsFundamentallyqualitative measures. Based on feelings and attitudes.Metrics and measurement are only a very small part of this, and they apply only to our sense of progress. They should be used to challenge and support our sense of progress.
- PaulUse Cucumber for storytesting system behavior. This enables users, customers and business analysts to collaborate with concrete examples and real data as the code is written. Also, UML can be combined with code analysis to increase our shared understanding of the invisible system structure.
- Paul
- Essence of coddling – don’t do things for the teams that they should be doing themselves.
- BrandonThe more complex an architecture is. The more detailed it is, the less likely it is to appear relevant to the people you serve… the more essentially simple it is, the more applicable and relevant it will seem.-- Remove the cruftThe more “cartoony” a domain model is, the more relevant it can be.
- Brandon“mutually agreed-upon design-decisions that shape a software-intensive system” Grady Booch
- Is your architecture part of the story, or just an irrelevant footnote to the conversation?Is your architecture law or a guidepost? Is it governance or guidance? You can get a sense for how relevant your architectures are by how often they are actually referred to day to day by the people who really matter…
- Architecture is so much more than a map or blueprints or diagrams or picturesYour architecture, ultimately, is a story. People need to see themselves in that story (they need to see a place for themselves and their concerns) This applies to both the customers AND the development teams, managers, testers, implementers If they don't, you'll never have their support, and you'll never be relevantThey need to connect with your architecture