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.
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
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
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?
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.
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
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.
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