[NCrafts] A Case for Outside-In Design

For a few decades, one of the most common approaches to software design is to first focus on the domain model (application layer), then persistence (data layer) and finally the user interface (presentation layer). But what are the pros and cons of this approach? Are there other alternatives? Are they viable?

In this presentation, Sandro will be talking about different design biases and the impact they have. He will then focus on Outside-In Design, explaining how our domain model can emerge and evolve when driven by the needs of external systems or users, avoiding speculation and wasted effort.

Transcript

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 Design 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 is 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. Non-Functional / Architectural Design Biases Performance Cloud Scalability CQRS/ES Micro Services Security Throughput Containers Actor Model Plugin etc… Hexagonal
6. Directional Design 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. (a.k.a. Outside-In) •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. •Tests, design, and execution flow point to the same direction (outside >> inside) Outside-In
7. Design techniques and their impact. (internal vs. external perspective)
8. Domain Model Inside-out development: an insider’s perspective
9. Domain Model and Abstractions
10. Domain Model Usefulness
11. Domain Model is a much wider concept than what we see in the middle of our hexagonal architecture.
12. A Case for Outside-In
13. The usefulness of a domain model needs to be evaluated from an outside perspective.
14. Clients & Company Functional Areas Services ecosystem Individual service Modules inside a service (OUTSIDE) Real domain / value (INSIDE) Abstract sub-domain model Bounded Contexts Candidates (business alignment) Software implementation (delivery mechanisms, use cases, sub-domain models, infrastructure, etc)
15. How to identify Functional Areas and Use Cases so that we can build useful domain models?
16. Product box Impact Mapping User Journey 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 Practices Level of abstraction
17. Product box Impact Mapping User Journey 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 Practices Level of abstraction
18. Identifying High Cohesive Functional Areas (birds-eye view)
19. Product Box • Omni-channel, with sales over the web, mobile, physical stores, and external market places. • Catalog 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.
20. 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. • Catalog 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
21. Product Box Goal: Identify the most important features of the system and their respective functional areas. Benefits: • Organize the architecture according to functional areas. • Help teams and POs to map features to functional areas. • Create a portfolio level backlog. • Enable team 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
22. Product box Impact Mapping User Journey 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 Practices Level of abstraction
23. 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 reduce dependencies and plan for continuous delivery?
24. 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
25. Let’s see a real example
29. 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
30. Product box Impact Mapping User Journey 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 Practices Level of abstraction
31. User Journey 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.
32. User Journey Mapping – View Catalogue
33. User Journey Mapping – Add to Cart
34. User Journey Mapping – View Cart
35. User Journey Mapping – Check Out
36. User Journey Mapping – Make the payment
37. Helps to identify the behaviour of each Functional Area and the relationship among them. User Journey Mapping
38. Analysing Functional Coupling
39. Product box Impact Mapping User Journey 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 Practices Level of abstraction
40. 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 contract and granularity of endpoints
41. Mockups and APIs
42. Mockups and APIs
43. API Contract
44. Mockups Help us identify the entry points (actions/use cases) of our domain model.
45. Product box Impact Mapping User Journey 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 Practices Level of abstraction
46. 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.
47. Outside-TDD
49. Incremental Development
50. Product box Impact Mapping User Journey 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 Practices Level of abstraction
51. Product Box • Identify the main areas and features of the system. Impact Mapping • Agree on what needs to be build according to the value. User Journey Mapping • Understand the business flow of each feature • Refine functional areas and identify use cases. Mockups • Define a contract between presentation and application layers according to the needs of the presentation layer Outside-In TDD • Build well- designed and tested features according to a well- defined contract. Main goals of each practice
52. Product Box • Every 6/12 months Impact Mapping • Every 3/4 months (milestone) User Journey Mapping • Around once a month (when exploring new flows) Mockups • Around once a week or two (when building new screens) Outside-In TDD • Daily (to build software) Frequency of each practice
53. Conclusion • We all have a design bias. • We need different perspectives. They complement each other. • Some perspectives are more important than others. • Exploring a system from outside keeps us focus on the real needs. • Our domain model is far wider than the modules inside a hexagon. It’s the whole ecosystem of services. • Avoid speculative development. Applications should evolve one feature at a time.
54. Outside-In TDD vs Classicist https://cleancoders.com/
55. Thank you sandro@codurance.com @sandromancuso http://codurance.com