When designing software we can start from the high-level concepts and then dive into the details or we can start from the small details and try to understand the higher-level concepts. London School TDD and Domain Driven Design typically approach design from a deductive point of view.
Classicist (Chicago School TDD) typically approach design from an inductive point of view. Both of them are powerful, but in specific context. Each of them has drawbacks in some situations.
Let's practice, discuss and learn when it is a better idea to be inductive or deductive.
Which Evolutionary Design tools to use so we can reach faster to a small easy to change software system that solves the business needs.
8. blog.adrianbolboaca.ro mozaicworks.com
Inductive Evolutionary Design
◊
Focus more on state behavior and less on
collaboration (interaction) behavior
ҩ Start with primitives
ҩ Test the logic of changing state
◊
Collaboration behavior is interesting just at the
limit of the system
9. blog.adrianbolboaca.ro mozaicworks.com
Inductive Evolutionary Design
1.Start from small details
a.Choose an entry point
b.Use Behavior Slicing to analyze the behaviors
c.Order the behaviors from simple to complex
2.Generalize the duplicated behaviors
a.Minimize non-accidental duplication in the code
b.Maximize the clarity of the concepts
10. blog.adrianbolboaca.ro mozaicworks.com
Inductive Evolutionary Design
3. Evolve small behaviors into design concepts
a.Move similar behavior in the same place
b.Maximize clarity of the moved behaviors
2.Generalize the design concepts
a.Use composition (or rarely inheritance)
b.Use Dependency Inversion to have a logical dependency
graph
3.Evolve the design concepts into components
a.Modules
b.Bounded contexts
11. blog.adrianbolboaca.ro mozaicworks.com
Inductive Design Characteristics
◊
Behavior is important, not implementation
◊
Representation doesn’t matter in the beginning
◊
Tests are generalized while duplication is
minimized
◊
Tests start by using primitives and end by
using design concepts
◊
The representation can be changed and the
tests should pass
13. blog.adrianbolboaca.ro mozaicworks.com
Inductive Design Layers
We start with primitives and we evolve the
design in successive layers:
ҩ Scalar Primitive type (string, int, array, etc)→
ҩ Primitive type Field OR Parameter→
ҩ Field Settings Class→
ҩ Parameter Data Structure→
ҩ Logic Pure function→
ҩ Pure function Class function→
ҩ Class Component→
16. blog.adrianbolboaca.ro mozaicworks.com
Deductive Evolutionary Design
◊
Focus more on collaboration (interaction)
behavior
◊
Create a scaffolding
ҩ Guiding Test
ҩ Bounded Context with business entities
ҩ Walking Skeleton
◊
Deduce the design concepts depending on the
scaffolding
17. blog.adrianbolboaca.ro mozaicworks.com
Deductive Evolutionary Design
1.Start from the scaffolding
a.Identify the entry point
b.Find the next layer of collaboration (interaction)
c.Check the collaboration behavior between the entry point
and the next layer
2.Move deeper to the next layer of collaboration
(interaction)
a.Find the next layer of collaboration (interaction)
b.Check the collaboration behavior between the entry point
and the next layer
18. blog.adrianbolboaca.ro mozaicworks.com
Deductive Evolutionary Design
3.Iteratively understand if you reached the end
a.Use guiding test
b.Have an acceptance test
2.Refactor the design concepts
a.Not having single responsibility
b.Being scattered across the system
c.That are unclear (purpose, naming, etc)
19. blog.adrianbolboaca.ro mozaicworks.com
Deductive Design Characteristics
◊
Behavior is important, not implementation
◊
Representation needs to be addressed minimally
◊
Tests are generic from the beginning
◊
Tests start by using design concepts
◊
The representation can be changed and the tests should pass
◊
The links between the design concepts is essential and made
through their APIs and collaborators
◊
If collaboration behavior changes, the tests make refactoring difficult
23. blog.adrianbolboaca.ro mozaicworks.com
Evolutionary Design Ideas
◊
The tests are pressure applied to existing design
◊
The production code is like clay that gets molded
depending on the pressure applied to it
◊
When evolving the design of a system we observe growth
patterns that simplify the resulting system
◊
Evolutionary Design is like helping your plants grow,
knowing what measures to take so they will be fruitful
24. blog.adrianbolboaca.ro mozaicworks.com
Anti-Patterns
◊
Focus on implementation details and not on
design concepts
◊
Consider that tests are the essential output of
TDD, and not well structured design elements
◊
Consider you know exactly the resulting
design, and don’t listen to the design smells
◊
Focus on the solution and not on the problem
25. blog.adrianbolboaca.ro mozaicworks.com
What’s Next?
◊
Experiment both Deductive and Inductive
approaches during katas or coderetreats
◊
Try both Deductive and Inductive approaches
in your production environment
◊
Watch my codecasts on TDD as if you Meant It
& more
blog.adrianbolboaca.ro/evolutionary-design
◊
Pair with many people and learn from them