A Case for Outside-In Design
1 like485 views
The document discusses various design biases and proposes an outside-in approach to software design. It outlines structural, procedural, object-oriented, functional, event-driven, and architectural biases. It then recommends starting with impact mapping to identify key goals, features and functional areas. Functional mapping is used to understand interactions between areas. Mockups and APIs define entry points and contracts. Outside-in test-driven development implements features in small slices to satisfy external needs, building just enough domain model. This approach aims to better align product and software design.
A Case for Outside-In Design
- 1. A Case for Outside-In Design @sandromancuso
- 2. Bias: inclination or prejudice for or against someone or something in way that is considered unfair.
- 3. We all have software design biases.
- 4. Structural Biases • Code matches the sequence which requirements were described. • Developers focus on implementing the behaviour, without worrying about mapping domain concepts. Procedural • Starts with an analysis on how data across features relate. A static view of the system is created. • Data model is used to create the database structure and entities. Behaviour away from data model.Data • Nouns are identified and become the center piece of the design. Verbs are then attached to nouns. • Behaviour is encapsulated in objects. Objects send messages to each other in order to collaborate.Object • Focus on a sequence of data transformations, internal steps first. Complex behaviour via composition. • Side effects and mutability are controlled and isolated from the main logic Functional • Focus on behaviour of the business features and then the data needed for that behaviour. • Verbs are more important than the nouns and are considered to provide the real business value.Service • Focus on not only the actions but also all events before and after each significant action of the system. • Events are a key design building block. Decoupling is a key aspect of design. Event
- 5. Operational & Architectural Design Biases Performance Architectural Patterns Scalability CQRS/ES Micro Services SOAThroughput Containers Actor Model Plugin etc… Hexagonal
- 6. Design Direction Biases •Persistence >> Domain Model >> User Interface. •Data, and the way it is stored, is the most important aspect of the design.Persistence •Domain Model >> Persistence >> User Interface. (a.k.a. Inside-Out) •Domain Model is the main focus. Persistence and user interface are details of implementation. Domain •User Interface >> Domain Model >> Persistence. •Usability is the main focus. Domain Model and Persistence should only exist to satisfy the external needs. User Interface •Similar to UI. Focus on incremental design and continuous delivery, splitting requirements in thin vertical slices. Describes how users interact with the system. •Tests, design, and execution flow point to the same direction (outside >> inside) Incremental Outside-In
- 7. Design techniques and their impact. (internal vs. external perspective)
- 10. Domain Model Adapter layer and accidental complexity Adapter Layer
- 11. Are we over or under engineering?
- 12. Domain Model is a much wider concept than what we see in the middle of a hexagon.
- 13. Product Backlog (small intersection) Small intersection, big problem
- 14. The goal of software design is to enable companies to continuously achieve their business goals.
- 15. A Case for Outside-In Design
- 16. The usefulness of a domain model needs to be evaluated from an outside (business) perspective.
- 17. Clients & Company Functional Areas Services ecosystem Service Modules (OUTSIDE) Real domain / value (INSIDE) Abstract sub-domain model Strategic design (business alignment) Software implementation (delivery mechanisms, use cases, sub-domain models, infrastructure, etc)
- 18. So, where do we start if we want to build a new system or a set of features related to a business outcome?
- 19. Product box Impact Mapping Functional Mapping User Interaction via Mockups Outside-In TDD/Design Omni-channel, with sales over the web, Catalog management per country. Outside-In Design Domain Modeling PracticesLevelofabstraction
- 20. Product box Impact Mapping Functional Mapping User Interaction via Mockups Outside-In TDD/Design Omni-channel, with sales over the web, Catalog management per country. Outside-In Design Domain Modeling PracticesLevelofabstraction
- 21. Identifying High Cohesive Functional Areas (birds-eye view)
- 22. Product Box • Omni-channel, with sales over the web, mobile, physical stores, and external market places. • Catalogue management per country. • Multi-warehouse management. • Product and supplier management. • Orders management and support. • Customers wish lists and favourites. • Multiple delivery options. • Multiple payment methods and anti- fraud detection. • Customer information management. • Sales and promotion. • Marketplace for franchisees.
- 23. Functional areas • Basket • Catalogue • Warehouse • Product • Supplier • Order • Customer • Delivery • Payment • Sales • Marketplace • Omni-channel, with sales over the web, mobile, physical stores, and external market places. • Catalogue management per country. • Multi-warehouse management. • Product and supplier management. • Orders management and support. • Customers wish lists and favourites. • Multiple delivery options. • Multiple payment methods and anti- fraud detection. • Customer information management. • Sales and promotion. • Marketplace for franchisees. Product Box
- 24. Product Box Goal: Identify the most important goals and features of the system and their respective functional areas. Benefits: • Creation of product roadmaps or portfolio level backlog. • Organize the architecture according to functional areas. • Help teams and POs to map features to functional areas. • Enable teams organisation and planning. • Help with the prioritisation of features related to strategic areas. Frequency: 1 session every 6 to 12 months. Duration: 3 hours People involved: Business and development team
- 25. Product box Impact Mapping Functional Mapping User Interaction via Mockups Outside-In TDD/Design Omni-channel, with sales over the web, Catalog management per country. Outside-In Design Domain Modeling PracticesLevelofabstraction
- 26. Finding answers to the following questions: - What should we build in the next few months? - Which features would give us a higher impact? - How do we identify bounded contexts and high level architecture? - How do we enable teams to work in parallel? - How do we show a plan of action to our stakeholders? - How do we reduce dependencies and plan for continuous delivery?
- 27. Impact Mapping Goal Actor 1 Impact 1 Deliverable 1 Deliverable 2 Impact 2 Deliverable 3 Actor 2 Impact 3 Deliverable 4 Deliverable 5 Impact 4 Deliverable 6 Deliverable 7
- 28. Let’s see a real example
- 32. Impact Mapping results • Business focus on high value features. • Bounded Contexts defined in collaboration with the business, enabling the ubiquitous language. • Service candidates and high-level architecture. • Technology stack of each bounded context / service can be discussed in isolation. • Easier to parallelize work across teams. • Concrete plan of action to stakeholders. • Easier to achieve continuous delivery due to system modularisation. Frequency: 1 session for each milestone (3/4 months). Duration: 1 day People involved: Business and development team
- 33. Product box Impact Mapping Functional Mapping User Interaction via Mockups Outside-In TDD/Design Omni-channel, with sales over the web, Catalog management per country. Outside-In Design Domain Modeling PracticesLevelofabstraction
- 34. Functional Mapping The goal is to understand: • External world (users/systems) interactions with our system(s). • Business flows. • Interactions between functional areas. • Separation of concerns across functional areas. • Define which functional areas should become services.
- 35. Functional Mapping - Catalogue
- 36. Functional Mapping – View Catalogue
- 37. Functional Mapping – Add to Cart
- 38. Functional Mapping – View Cart
- 39. Functional Mapping – Check Out
- 40. Functional Mapping – Make the payment
- 41. Helps to identify the behaviour of each Functional Area and the relationship among them. Functional Mapping
- 44. Product box Impact Mapping Functional Mapping User Interaction via Mockups Outside-In TDD/Design Omni-channel, with sales over the web, Catalog management per country. Outside-In Design Domain Modeling PracticesLevelofabstraction
- 45. Mockups and APIs The goal is to: •Identify the behaviour (actions/use cases) each service will need to provide to the external world. •Identify the scope of the delivery mechanism. •Define the granularity and contract of end-points
- 46. Let’s see a example
- 47. Mockups and APIs
- 48. Mockups and APIs
- 49. API Contract
- 50. Mockups Help us identify the entry points (actions/use cases) of our domain model.
- 51. Product box Impact Mapping Functional Mapping User Interaction via Mockups Outside-In TDD/Design Omni-channel, with sales over the web, Catalog management per country. Outside-In Design Domain Modeling PracticesLevelofabstraction
- 52. Outside-TDD / Design The goal is to: •Implement the specified behaviour in each service. •Build features in small vertical slices. •Use just-in-time design to build the delivery mechanism and domain model. •Build just enough well-designed and tested code to satisfy the external need.
- 53. Outside-TDD
- 56. Product box Impact Mapping Functional Mapping User Interaction via Mockups Outside-In TDD/Design Omni-channel, with sales over the web, Catalog management per country. Outside-In Design Domain Modeling PracticesLevelofabstraction
- 57. Product Box • Every 6/12 months Impact Mapping • Every 3/4 months (milestone) Functional Mapping • Around once a month (when exploring new flows) Mockups • Once every 1 or 2 weeks (when building new screens) Outside-In TDD • Daily (while building software) Frequency of each practice
- 58. Where do we go from here?
- 59. Business product design Technology software design We need to widen the intersection
- 60. Aligning product and software design https://www.youtube.com/user/codurance