Slide 1
Slide 1 text
Photo by Mathew Schwartz on Unsplash
Disentangling legacy software
approached with Domain-Driven Design
Kenny Baas-Schwegler
@kenny_baas
Slide 2
Slide 2 text
@kenny_baas
Slide 3
Slide 3 text
@kenny_baas
Slide 4
Slide 4 text
@kenny_baas
Slide 5
Slide 5 text
@kenny_baas
Slide 6
Slide 6 text
@kenny_baas
Slide 7
Slide 7 text
@kenny_baas
Slide 8
Slide 8 text
@kenny_baas
Slide 9
Slide 9 text
@kenny_baas
Slide 10
Slide 10 text
@kenny_baas
Slide 11
Slide 11 text
@kenny_baas
Slide 12
Slide 12 text
@kenny_baas
“The next internet explorer type microsoft legacy for generations to come”
No I won’t rant a lot about
Slide 13
Slide 13 text
Legacy Software
– Kenny Baas-Schwegler
Photo by Gabriella Clare Marino on Unsplash
I <3
@kenny_baas
Slide 14
Slide 14 text
@kenny_baas
https://wirfs-brock.com/blog/2019/03/20/growing-your-personal-design-heuristics/
Heuristic
“anything that provides a plausible aid or direction in the solution of a problem but is
in the final analysis unjustified, incapable of justification, and potentially fallible.
– Billy Vaughn Koen - Nuclear Engineer
Slide 15
Slide 15 text
Photo by Evan Qu on Unsplash
Design heuristic
“Favour monolithic architecture over microservices architecture”
@kenny_baas
Slide 16
Slide 16 text
@kenny_baas
Slide 17
Slide 17 text
Photo by Christopher Burns on Unsplash
But…But I thought we should get rid of
Legacy software, not create more?
@kenny_baas
Slide 18
Slide 18 text
Photo by Manish Tulaskar on Unsplash
Monolithic architecture != BAD
Monolithic architecture != Legacy
@kenny_baas
Slide 19
Slide 19 text
@kenny_baas
Legacy software
In computing, a legacy system is an old method, technology, computer system, or
application program/code, "of, relating to, or being a previous or outdated computer
system," yet still in use.
https://en.wikipedia.org/wiki/Legacy_system
Slide 20
Slide 20 text
@kenny_baas
A single-tiered software application in which
different components combined into a single
program form a single deployable unit. It can
be a MVC approach or an API with a
database.
Monolithic architecture
Slide 21
Slide 21 text
@kenny_baas
Slide 22
Slide 22 text
@kenny_baas
To communicate effectively, the code must be based on the same language
used to write the requirements,
the same language that the developers speak with each other
and with domain experts
- Eric Evans
Slide 23
Slide 23 text
@kenny_baas
https://www.huffingtonpost.co.uk/entry/american-tweets-about-great-british-bake-off_uk_61733eaee4b03072d6f6d012
Slide 24
Slide 24 text
@kenny_baas
Slide 25
Slide 25 text
We all know or should know that language is fluid, liquid, subject to the
whims of the people. Language evolves, as it should. Because language
changes to accommodate new users, the older users resist and
complain.
http://tednellen.blogspot.com/2013/04/language-is-fluid.html
@kenny_baas
Slide 26
Slide 26 text
@kenny_baas
It is not the domain experts knowledge
that goes to production, it is the
assumption of the developers
that goes to production
- Alberto Brandolini
Slide 27
Slide 27 text
Instead of one canonical language,
create multiple bounded languages
@kenny_baas
Slide 28
Slide 28 text
@kenny_baas
Business
Architects
Developers
Slide 29
Slide 29 text
@kenny_baas
Slide 30
Slide 30 text
@kenny_baas
Slide 31
Slide 31 text
@kenny_baas
Slide 32
Slide 32 text
A straight line between 2 points
corresponds to a compass direction in
reality..
@kenny_baas
Slide 33
Slide 33 text
A straight line between 2 points corresponds to
a compass direction in reality..
• Except for points located in Greenland
• Except for points located in Africa
@kenny_baas
Slide 34
Slide 34 text
@kenny_baas
A model is a simplified representation of a thing or phenomenon
that intentionally emphasizes certain aspects while ignoring others.
Abstraction with a specific use in mind.
— Rebecca Wirfs-Brock
Slide 35
Slide 35 text
@kenny_baas
Business
Architects
Developers
Slide 36
Slide 36 text
Photo by Evan Qu on Unsplash
Guiding heuristic
Start communicating business change in
contextual boundaries that form the bounded context
(purpose, need, responsibility, promise, user problem)
@kenny_baas
Slide 37
Slide 37 text
@kenny_baas
@kenny_baas
Slide 38
Slide 38 text
Photo by Evan Qu on Unsplash
Design heuristic
When designing new bounded contexts, they should have one team who is
owning that bounded context. A team can have multiple bounded context
@kenny_baas
Slide 39
Slide 39 text
Photo by Gloria Cretu on Unsplash
Recap
● A legacy system is an old application program/code still in use.
● Monolith is a deployment strategy.
● Legacy != Monolith, and most legacy software is build as monoliths
● Most monoliths components are not designed with a DDD approach,
creating a disconnect with the business strategy and creating a big ball of mud.
@kenny_baas
Slide 40
Slide 40 text
Photo by Felix Mooneeram on Unsplash
BigScreen
● Fictitious company
● International cinema chain with 80 cinema’s located in 12 different countries
● Custom software system
● The current system is completely entangled, a big ball of mud (BBoM) that has
been around for many years
@kenny_baas
Slide 41
Slide 41 text
@kenny_baas
Big Ball of Mud
Software system that
lacks a perceivable
architecture and the
model is implicit.
Slide 42
Slide 42 text
Photo by Fusion Medical Animation on Unsplash
Then came Covid-19
@kenny_baas
Slide 43
Slide 43 text
@kenny_baas
Requirements
● Reopen in approx 2-3 months
● 1.5 meters apart from reservations
● Sign a health check
● Able to go back when needed
Slide 44
Slide 44 text
Photo by Evan Qu on Unsplash
Guiding heuristic
Discover and identify bounded context with EventStorming
@kenny_baas
Slide 45
Slide 45 text
@kenny_baas
* Disclaimer: Real life Eventstormings are much more chaotic
Slide 46
Slide 46 text
Photo by Evan Qu on Unsplash
Guiding heuristic
Split according to natural boundaries (pivotal events)
@kenny_baas
Slide 47
Slide 47 text
@kenny_baas
* Disclaimer: Real life Eventstormings are much more chaotic
Slide 48
Slide 48 text
Photo by Evan Qu on Unsplash
Guiding heuristic
Pick some boundaries to start with and iterate.
@kenny_baas
Slide 49
Slide 49 text
Photo by Evan Qu on Unsplash
Design heuristics
● Split according to the language.
● Split according to the departments.
● Split according to the users
● Split according to the users their needs
@kenny_baas
Slide 50
Slide 50 text
@kenny_baas
* Disclaimer: Real life Eventstormings are much more chaotic
Slide 51
Slide 51 text
@kenny_baas
Using collaborative modelling to build a
shared understanding of your domain and use it to
guide your design _is_ the philosophy behind DDD
though. The rest is principles, patterns, and practices.
— Mathias Verraes
https://verraes.net/2021/09/what-is-domain-driven-design-ddd/
Slide 52
Slide 52 text
@kenny_baas
Requirements
● Reopen in approx 2-3 months
● 1.5 meters apart from reservations
● Sign a health check
● Able to go back when needed
Slide 53
Slide 53 text
@kenny_baas
3 Strategies + Evolution
1. Bubble context
2. Autonomous bubble
3. Exposing Legacy as a service (LaaS)
➔ Expanding a bubble
https://www.domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf
Slide 54
Slide 54 text
@kenny_baas
@kenny_baas
Slide 55
Slide 55 text
@kenny_baas
Anti-corruption Layer (ACL)
Translation layers can be simple, even elegant, when bridging
well-designed bounded contexts with cooperative teams. But when
control or communication is not adequate to pull off a shared kernel,
partner or customer/supplier relationship, translation becomes more
complex. The translation layer takes on a more defensive tone.
Therefore:
As a downstream client, create an isolating layer to provide your system
with functionality of the upstream system in terms of your own domain
model. This layer talks to the other system through its existing interface,
requiring little or no modification to the other system. Internally, the
layer translates in one or both directions as necessary between the two
models.
ACL is more than a Translation Layer!
From: https://www.domainlanguage.com/ddd/reference/
https://virtualddd.com/sessions/20
Slide 56
Slide 56 text
@kenny_baas
Slide 57
Slide 57 text
@kenny_baas
Repositories
For each type of aggregate that needs
global access, create a service that can
provide the illusion of an in-memory
collection of all objects of that aggregate’s
root type.
Set up access through a well-known global
interface. Provide methods to add and
remove objects, which will encapsulate the
actual insertion or removal of data in the
data store.
public interface AuditoriumSeatings
{
Task GetAuditoriumSeating
(ShowId showId);
}
Slide 58
Slide 58 text
@kenny_baas
public class AuditoriumSeatingAdapter : AuditoriumSeatings
{
private readonly IProvideAuditoriumLayouts _auditoriumSeatingRepository
;
private readonly IProvideCurrentReservations _reservationsProvider
;
public AuditoriumSeatingAdapter
(IProvideAuditoriumLayouts auditoriumSeatingRepository
,
IProvideCurrentReservations reservationsProvider
)
{
_auditoriumSeatingRepository = auditoriumSeatingRepository
;
_reservationsProvider = reservationsProvider
;
}
public async Task GetAuditoriumSeating
(ShowId showId)
{
var auditoriumDto = await _auditoriumSeatingRepository
.GetAuditoriumSeatingFor
(showId.Id);
var reservedSeatsDto = await _reservationsProvider
.GetReservedSeats
(showId.Id);
return AdaptAuditoriumSeatingDto(auditoriumDto, reservedSeatsDto
);
}
private static AuditoriumSeating AdaptAuditoriumSeatingDto(AuditoriumDto auditoriumDto,
ReservedSeatsDto reservedSeatsDto
)
{
var rows = new Dictionary();
foreach (var (rowName, seatDtos) in auditoriumDto.Rows)
{ ………………
@kenny_baas
Slide 59
Slide 59 text
@kenny_baas
Ports and Adapters
The hexagonal architecture, or
ports and adapters architecture,
is an architectural pattern used
in software design. It aims at
creating loosely coupled
application components that can
be easily connected to their
software environment by means
of ports and adapters. This
makes components
exchangeable at any level and
facilitates test automation.
Slide 60
Slide 60 text
@kenny_baas
@kenny_baas
Slide 61
Slide 61 text
Photo by Evan Qu on Unsplash
Design heuristic
(repeated)
“Favour monolithic architecture over microservices architecture”
@kenny_baas
Slide 62
Slide 62 text
@kenny_baas
@kenny_baas
Slide 63
Slide 63 text
Photo by Evan Qu on Unsplash
Design heuristics
(Competing)
1. “Integrate through an API on application layer”
2. “Integrate through an API on the database layer”
@kenny_baas
Slide 64
Slide 64 text
@kenny_baas
3 Strategies + Evolution
1. Bubble context
2. Autonomous bubble
3. Exposing Legacy as a service (LaaS)
➔ Expanding a bubble
https://www.domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf
Slide 65
Slide 65 text
@kenny_baas
@kenny_baas
Slide 66
Slide 66 text
@kenny_baas
@kenny_baas
Slide 67
Slide 67 text
@kenny_baas
@kenny_baas
Slide 68
Slide 68 text
Photo by Evan Qu on Unsplash
Guiding heuristic
“Either remove a bubble context, or dedicate resources and people to move
towards an autonomous bubble context”
@kenny_baas
Slide 69
Slide 69 text
Photo by Yong Chuan Tan on Unsplash
Black hole anti-pattern
When a POC is put to production and not getting the time and people to
decouple, making the bubble burst
and be absorbed back by the Big Ball of Mud
@kenny_baas
Slide 70
Slide 70 text
@kenny_baas
@kenny_baas
Slide 71
Slide 71 text
Photo by Evan Qu on Unsplash
Value heuristic
“Use Test-Driven Development and good unit testing practices
to get fast feedback, and become more confident on changes”
@kenny_baas
Slide 72
Slide 72 text
@kenny_baas
3 Strategies + Evolution
1. Bubble context
2. Autonomous bubble
3. Exposing Legacy as a service (LaaS)
➔ Expanding a bubble
https://www.domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf
Slide 73
Slide 73 text
@kenny_baas
@kenny_baas
Slide 74
Slide 74 text
Photo by Evan Qu on Unsplash
Guiding heuristic
“Don’t rebuild functionality that works as intended
and has no or little expected changes coming up.
(Including architectural characteristics/qualities)”
@kenny_baas
Slide 75
Slide 75 text
@kenny_baas
Follow Jabe Bloom: https://twitter.com/cyetain
Follow Ben at HiredThought: https://twitter.com/HiredThought
Slide 76
Slide 76 text
@kenny_baas
@kenny_baas
Slide 77
Slide 77 text
Photo by Evan Qu on Unsplash
Guiding heuristic
“You can use Monolith and Microservices architecture together!!”
@kenny_baas
Slide 78
Slide 78 text
@kenny_baas
https://github.com/ddd-crew/ddd-starter-modelling-process
Slide 79
Slide 79 text
@kenny_baas
3 Strategies + Evolution
1. Bubble context
2. Autonomous bubble
3. Exposing Legacy as a service (LaaS)
➔ Expanding a bubble
https://www.domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf
Slide 80
Slide 80 text
@kenny_baas
@kenny_baas
Slide 81
Slide 81 text
Photo by Evan Qu on Unsplash
Design heuristic
“Implement requirements and information
based on the responsibility of your bounded context”
@kenny_baas
Slide 82
Slide 82 text
@kenny_baas
3 Strategies + Evolution
1. Bubble context
2. Autonomous bubble
3. Exposing Legacy as a service (LaaS)
➔ Expanding a bubble
https://www.domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf
Slide 83
Slide 83 text
@kenny_baas
@kenny_baas
Slide 84
Slide 84 text
@kenny_baas
Reference from Trond Hjorteland: Sociotechnical System
https://www.researchgate.net/publication/306242078_Assessing_the_impact_of_new_technology_on_complex_sociotechnical_systems
Slide 85
Slide 85 text
Photo by David Ramírez on Unsplash
“Every tradeoff we make, that we might see as technical
has also user and biz effects and are hence a sociotechnical tradeoff”
– Ruth Malan / @ruthmalan
@kenny_baas
Slide 86
Slide 86 text
Photo by Gabriella Clare Marino on Unsplash
“Our problems are not legacy software systems,
these can be changed giving enough time and people.
Our problem is we are dealing with legacy sociotechnical system,
who have legacy best practices competing with emerging practices”
@kenny_baas
Slide 87
Slide 87 text
#CatTax
@kenny_baas
Baasie.com
https://speakerdeck.com/baasie
https://virtualddd.com/
@kenny_baas