Great technologies, programming languages and tools are used when building software. That is good and right. But unfortunately, it is often lost sight of the fact that the decisive factor is not the technology, but the *business domain*. If we do not map the domain language and the business processes in the software, then it will not help our users in their work. No technology in the world can protect us from this. In this talk, I'll show you how you can identify problems in an existing legacy system that could be solved with Domain-Driven Design. We will see problems such as: large entities that are used all over the system, how we could divide them into smaller entities according to the business domain and how we should cut the source code into bounded contexts. All this will be done with many examples from analysis tools that help us to see the system on the level above the source code.

1. 1
WPS - Workplace Solutions GmbH //// Hans-Henny-Jahnn-Weg 29 //// 22085 HAMBURG
It’s all about the domain, honey !
Experiences from 15 years of Domain-Driven Design
Dr. Carola Lilienthal @cairolali cl@wps.de
Hi everybody! In this talk, I'll show you how to build systems in a way that makes
sense for the business and how Domain Driven Design (DDD) can help us do
that.

2. CAROLA
... My name is Carola ...
3

3. On twitter you can find me under my handle
4

4. @cairolali
@cairolali

5. Quelle: http://www.schulbilder.org/malvorlage-informatiker-i10418.html
... I have studied computer science….

6. … at the university of hamburg and gained the diploma in 1995 I started to work as a
programmer and discovered my love for architecture. And in 2004

7. Someone showed me the book of Eric Evans and I knew: This is it! It is difficult to read,
but it‘s worth it. Please dont stop at page 100! Because the interesting part starts at
page 120
8

8. ARCHITECT
So I started to work as a programmer and architect and used DDD in all my projects. It is
great!
9

9. www.sustainable-software-architecture.com
All this is written down in my book Sustainable Software Architecture with many
examples and pitfalls that one encounters on the way to good architecture.
10

10. My homebase is the company WPS where we develop all our systems following DDD.
We started with 12 programmers in 2000 and today we are 140 programmers,
architects, ux-designers and requirement engineers. And we love good software that
lives a long time and comes from the domain.
11

11. Berlin
Hamburg
We hire
throughout
Germany!
Wir stellen
deutschlandweit
ein!
Stuttgart
We are located in Hamburg and Berlin and we
12

12. @cairolali
WHAT IS THE GOAL?
Sustainable
Architecture
the sad norm…
Release cycle or time
Number
of
delivered
feature
per
release
What is sustainable architecture
13

13. @cairolali
10 42
81
165
120 15 Mio
5 Mio
1 Mio
500.000
100.000
Size in Lines of Code
During and after my PhD, we analyzed a great many systems of different ages, sizes, and
programming languages. On this slide here, you see sizes ranging from 100,000 to 15
million lines of code. The pie chart in the middle shows how many systems of which size
we have analyzed. 120 systems from a size up to 100,000 LOC, 150 systems from a size
up to half a million LOC and so on. Some were even up to 15 million loc.
Many of theses systems are developed in modern programming languages (Java, C#...),
but they frustrate their developers because they have accumulated technical debt and
complexity over the years. and unfortunately, some of them are microservice
architectures -
14
Dr. Carola Lilienthal, C1 WPS

14. @cairolali
NEW SOLUTION: MICROSERVICES!
the great new architectural style that was supposed to solve all our problems when we
were told about it around 2010.
It used to be that people would call me and say, “Carola, we have a legacy system, and
we need help! It's getting more expensive and slower to maintain. Can you help us break
the system into microservices." Today they call and say, “Carola, we have a microservice
architecture and maintenance is getting more expensive and slower. What are we doing
wrong?“
Yes, what is wrong? Well, with a lot of microservice architectures, people have made the
same mistakes they made with monoliths before.
15

15. @cairolali
NEW SOLUTION – SAME PROBLEM
Simon Brown
I stole this diagram from simon brown because it explaines so well what was forgotten.
The people forgot that a good architecture is about creating independent modules.
therefore the x axis is labeled with ”modularity”. A modular architecture - is the opposite
to a big ball of mud. In a modular architecture independence of moduls is a top priority.
If not, then you have a big ball of mud. No matter if you have a monolith or a greater
number of deployment units - what is shown on the y-axis. If you don't have
independent modules, you have a big ball of mud in your distributed system. and that is
much worse than a monolithic big ball of mud. If modularity is not your top priority your
system will look like this
16

16. @cairolali
▪ 15 years of development
▪ 3 Million LOC in Java
▪ 463 tangled classes from 10 modules
▪ This cycle contains 500.000 LOC
BIG BALL OF MUD ON CLASS LEVEL
The diagramm on the right shows a class clycle, a strongly conntected component, In
Lines of code this classclycle contains about 500.000 LOC and it spans 10 domain
modules each one with a different Color in the diagramm. The whole system has
3.000.000 LOC. which means that the cycle is a big part of the system. 30 developers
have been working on this system for 15 years. If you change one class in this cycle, you
have to check the whole cyclic structure to exclude possible side effects. This greatly
slows down maintenance and enhancements.
17

17. @cairolali
▪ 20 years of developement
▪ 10 Million Lines of Code in Java
▪ 90 Modules
▪ No dependency control!
BIG BALL OF MUD ON MODULE LEVEL
Another example – even bigger: 10 million lines of code developed in Java over the last
20 years. When they started, nobody told them about modularity, monolith and
microservices. These ideas did not exist at that time. The result is 90 modules strongly
connected – a real big ball of mud - and a whole lot extra work for maintenance and
enhencements. Nobody has reduced or controled the dependencies in theses complex
structures. What can we do, to prevent this in our microservice architectures?
18

18. @cairolali
▪ Within a module:
▪ high cohesion = strong coupling
▪ Single Responsibility Principle
▪ Separation of concern
▪ Outside a module:
▪ loose coupling = low coupling
▪ Information hiding
▪ Separation of concern
HIGH COHESION AND LOOSE COUPLING
Well we do have very old principles at hand to prevent the big ball of mud in our
architectures: high cohesion and loose coupling. Within a module, the classes or
packages should work together to fulfill one responsibility. This responsibility connects
them strongly together and creatrs high cohesion. Other resonsibilities should be
separated into their own module. Outside of the module we want loose coupling which
means low coupling – one module doesn‘t need much from another module. A module
should be complete from a domain point of view!
From outside of the module only relevant features should be visible and accessible.
Details of the implementation should remain hidden. A good modular architecture that
follows these principles would look like this:
19

19. @cairolali
HIGH COHERSION AND LOW COUPLING FOR MODUES
Loose coupling = As little coupling as possible!
Technical
Layering
Module B
Module A Module C
User Interface User Interface
User Interface
Domain
Application
Domain
Application
Domain
Application
we see three Modules here, each of which should have a responsibility and therefore
have high cohesion within. The key point is that we should build this architecture in such
a way that we have as little coupling as possible between modules. but this is only
possible if
20

20. @cairolali
THE NEED OF DOMAIN ARCHITECTURE
An architecture (with or without
microservices) only then has
high cohesion and low coupling
if it follows a
domain architecture!
there is an idea of a domain architecture. Domain driven design has given us the
knowlegde to create independent modules. One module for the sales context and
another one for the support context. This is such a wonderful idea and it works. It
creates modules that have high cohesion and low coupling which means dependency
control. But unfortunately not many systems have a domain architecture.
The other day a client called me and said: Carola, we need help. We are having a
microservice architecture (Yes! I thought) for our platform where customers can sell
their second-hand vehicles. We have 270 microservices. (oh, quite a lot…) and what is
the problem: Well if we want to change something in the database: we have to discuss
this with all teams. What?
21

21. @cairolali
ONE DOMAIN MODEL AND DATABASE FOR ALL
Module B
Module A Module C
User Interface User Interface
User Interface
Domain
Application Application Application
Well we looked at the thing and each microservice was using a library called model.jar. I
asked them what this is: Well that‘s the interface to the database. The one and onlys
database….When the second microservice was built they thought that they could reuse
the work of the first team on the domain model. So they took the model.jar. Enhanced it
for their purpose and ended up with an overall domain model.
22

22. @cairolali
ONE SHARED MODEL
Several domain use cases Models allocated to their use cases
I have an example for you with a simular problem where we tried to find a solution: a
company called us to look at their architecture and help them to divide it into
microservices. I asked: What kind of architecture do you have? They said: our
architecture follows use cases – a criterion from the domain! I thought, finally no
layered architecture! this will be exciting. What you see here is the architecture that we
put on the source code with a tool. for each use case we have created a rectangle and
written the name of the use case next to it <klick>: Mailing, Importexport, remove and
so on. The dependencies between the system parts are shown on the right side of the
diagram. the green arcs represent relationships from top to bottom. the red arcs
represent relationships from bottom to top. Mailing uses importexport via the green arc.
And remove uses importexport via the red arc. After collecting the use cases we came to
a part of the system called Model<klick>. You guessed it: the equivalent of model.jar.
This is not a good idea in a modular architecture, so we tried to distribute the classes
from model among the use cases. <klik< on the right side you can see the result. There
are much more dependencies between the use cases now. They appeared because we
moved classes from the model rectangle to the use cases rectangles. So many
dependencies hidden in the model! We see another big ball of mud.
23

23. @cairolali
Security Business
Bild 215
Account Managing
Account Credit
Customer
Credit Business
Presentation
Application
Presentation
Application
Presentation
Application
Security
A bank with three business areas: account managing, credit business and security
business. These three areas use the same classes Account, customer, Credit and Security
to fullfil their work.
24

24. @cairolali
Bild 216
Security Business
Credit Business
Account Managing
Account
Credit
Security
Credit
Customer
Presentation
Application
Presentation
Application
Presentation
Application
Customer
Credit
Account Securities
Account
Security
Customer
Credit
Security
If we want to break them down to the bottom of the domain model, we have to have
much more specific domain model classes: a credit customer and a credit account as
well as a security customer and a security account.
25

25. @cairolali
MODELS IN MICROSERVICES
➔ domains need to be divided into subdomains with smaller models
▪ Separate models
▪ Allow independent changes (separation of concern)
▪ have to represent a smaller
set of the requirements (high cohesion)
▪ Need a clear boarder (loose coupling)
➔ Each model and its subdomain should be small enough to be programmed by one team.
So please, if you are building or having a microservice architecture, try to <klick> divide
your domain into subdomains with small models
Try to <klick> create separated models. Because than you will allow <klick> independent
changes you will have <klick> high cohesion and <klick> loose coupling.
And your teams can work independently <klick> because each model and its subdomain
should be small enough to be programmed by one team.
Otherwise, your teams will feel <klick> like the chickens on the right side: the chickens
eat pieces of bread. Unfortunately some stupid children have tied those bread pieces
together. The chicken swallow them and are no longer <klick> independent. They might
even <klick> die together. Lets look at a solution:
26

26. that's exactly what ddd wants to help us with: The goal of software development is to
translate the domain knowledge into the software
27

27. @cairolali
STRATEGIC DESIGN
▪ Find the subdomains in the
domain and decompose your
software accordingly.
▪ Set explicit boundaries with
the bounded contexts for
▪ domain-oriented parts in
the software and
▪ in the team organization
▪ Goal: high cohesion
+ loose coupling
Domain Software System
Bounded
Context A
Bounded
Context B
Team A
Team B
Bounded
Context C
Team C
Subdomain
A
Subdomain
B
Subdomain
C
Our <klick> software system supports users in their work in a <klick> domain.
DDD tells us that in a domain above a certain size, there should be subdomains
<klick> that can help us divide our software into bounded contexts <klick>. Each
<klick> bounded context sets explicit boundaries for individual domain-oriented
parts in the software and in the <klick< team organization. Each bounded context
is handled by exactly one team. We do all this because our goal <klick> is high
cohesion and loose coupling for our bounded contexts.
let's go back to the process in the cinema and see what we can do there.
28

28. Event Storming https://www.eventstorming.com/
For an event storming session, we meet with the users and developers and model the
processes in the domain with sticky notes on the wall. Each sticky note represents a
domain event. All participants are invited to stick notes, which are then discussed and
sorted with the whole group afterwards. This way you get a quick overview of the
process without thinking about software.
Today, of course, we're doing Event Storming remotely on a Miroboard.
29

29. Domain Storytelling https://domainstorytelling.org/
In a session for domain storytelling, we also meet with the users and developers and
model the processes from the domain with actors who exchange domain objects and
concepts. Today, we also do this remotely with the open-source tool domainstory
modeler. Let's look at this with an example.
30

30. @cairolali
TICKET AGENT
CUSTOMER
WEEKLY SCHEDULE
<< work in progress>>
REQUESTED NUMBER
OF SEATS
AUDITORIUM PLAN
LIST OF AUDITORIUM
PLANS
SOLD SEATS
TICKETS
FILM SHOW
FOUND
SEATS
AUDITORIUM PLAN
WEEKLY SCHEDULE
<< finalized>>
FILM DISTRIBUTOR
CINEMA
MANAGER
AD
AGENCY ADVERTISMENT
BOOKING PLAN
PLAN FOR
FILM SHOWS
COUNTRYWIDE
NUMBER OF VISITORS
AVAILABILITY
OF FILMS
1
6
2
10
5
3
8
4
7
9
11
12
13
14
AUDITORIUM PLAN
15
STARTS
WORKING ON
CHECKS THE
NEGOTIATES
WITH
FINALIZES
THE
AND CREATES FOR
THE UPCOMMING
WEEK
MONEY TICKETS
TICKETS
ASKS FOR
FOR A
OPENS A
CLOSES THE
FROM THE
OFFERS
TO GIVES
TO
SEARCHES
ON
THE
ON
THE
MARKS
PRINTS
GIVES THE
TO
THE
This is a domain story for a small art house cinema. In this program cinema there is the
<klick> cinema manager and the <klick> ticket agent. Once a week in this cinema is
issued <click> a new weekly schedule for the next week. The <click> process starts in the
upper left corner when the advertising agency sends the plan for the advertising
bookings. Once the cinema manager has received this plan, he <click> starts working on
the Weekly schedule with his super great legacy system Cinesmall. The small yellow
flash on the icon of the weekly schedule indicates that the Cinesmall software is used
here.
Next, the cinema manger <klick> gets the plan for the possible film shows from the film
distributors and <klick> he looks at the nationwide number of visitors. He <klick>
negotiates with the film distibutor which films he can get and finally <klick> finalizes the
weekly schedule. Our legacy system Cinesmall then <klick> generates auditorium plans
and the ticket agent can start selling tickets for the now scheduled film shows. <klick>
The customer now comes to the cinema and <klick> asks for tickets for a certain film
show. <klick> The ticket agent checks the auditorium plan to see if he can find suitable
seats in the auditorium for the desired film show and <klick> sells the seats to the
Customer.
This is very domain specific! You don’t find any technical terms in this domain story this
is, because DDD asks us to
31

31. @cairolali
TICKET AGENT
WEEKLY SCHEDULE
<< work in progress>>
REQUESTED NUMBER
OF SEATS
AUDITORIUM PLAN
LIST OF AUDITORIUM
PLANS
SOLD SEATS
TICKETS
FILM SHOW
FOUND
SEATS
AUDITORIUM PLAN
WEEKLY SCHEDULE
<< finalized>>
FILM DISTRIBUTOR
CINEMA
MANAGER
AD
AGENCY ADVERTISMENT
BOOKING PLAN
PLAN FOR
FILM SHOWS
COUNTRYWIDE
NUMBER OF VISITORS
AVAILABILITY
OF FILMS
1
6
2
10
5
3
8
4
9
11
12
13
14
AUDITORIUM PLAN
15
STARTS
WORKING ON
CHECKS THE
NEGOTIATES
WITH
FINALIZES
THE
AND CREATES FOR
THE UPCOMMING
WEEK
MONEY TICKETS
TICKETS
ASKS FOR
FOR A
OPENS A
CLOSES THE
FROM THE
OFFERS
TO GIVES
TO
SEARCHES
ON
THE
ON
THE
MARKS
PRINTS
GIVES THE
TO
THE
Trigger
Trigger
CUSTOMER
7
If you look closely at the process, you can see there are two entries, that is, two triggers
that set different parts of the process in motion. this is an important indicator that there
could be two subdomains in the domain here.
32

32. @cairolali
TICKET AGENT
WEEKLY SCHEDULE
<< work in progress>>
REQUESTED NUMBER
OF SEATS
AUDITORIUM PLAN
LIST OF AUDITORIUM
PLANS
SOLD SEATS
TICKETS
FILM SHOW
FOUND
SEATS
AUDITORIUM PLAN
WEEKLY SCHEDULE
<< finalized>>
FILM DISTRIBUTOR
CINEMA
MANAGER
AD
AGENCY ADVERTISMENT
BOOKING PLAN
PLAN FOR
FILM SHOWS
COUNTRYWIDE
NUMBER OF VISITORS
AVAILABILITY
OF FILMS
1
6
2
10
5
3
8
4
9
11
12
13
14
AUDITORIUM PLAN
15
STARTS
WORKING ON
CHECKS THE
NEGOTIATES
WITH
FINALIZES
THE
AND CREATES FOR
THE UPCOMMING
WEEK
MONEY TICKETS
TICKETS
ASKS FOR
FOR A
OPENS A
CLOSES THE
FROM THE
OFFERS
TO GIVES
TO
SEARCHES
ON
THE
ON
THE
MARKS
PRINTS
GIVES THE
TO
THE
Trigger
Trigger
once a week
CUSTOMER
7
In addition, the two subprocesses are also decoupled in terms of time. The left one is
performed once a week and …….
33

33. @cairolali
TICKET AGENT
WEEKLY SCHEDULE
<< work in progress>>
REQUESTED NUMBER
OF SEATS
AUDITORIUM PLAN
LIST OF AUDITORIUM
PLANS
SOLD SEATS
TICKETS
FILM SHOW
FOUND
SEATS
AUDITORIUM PLAN
WEEKLY SCHEDULE
<< finalized>>
FILM DISTRIBUTOR
CINEMA
MANAGER
AD
AGENCY ADVERTISMENT
BOOKING PLAN
PLAN FOR
FILM SHOWS
COUNTRYWIDE
NUMBER OF VISITORS
AVAILABILITY
OF FILMS
1
6
2
10
5
3
8
4
9
11
12
13
14
AUDITORIUM PLAN
15
STARTS
WORKING ON
CHECKS THE
NEGOTIATES
WITH
FINALIZES
THE
AND CREATES FOR
THE UPCOMMING
WEEK
MONEY TICKETS
TICKETS
ASKS FOR
FOR A
OPENS A
CLOSES THE
FROM THE
OFFERS
TO GIVES
TO
SEARCHES
ON
THE
ON
THE
MARKS
PRINTS
GIVES THE
TO
THE
Trigger
Trigger
once a week
each time a
customer asks
for a ticket
CUSTOMER
7
the right one whenever the customer comes by.
34

34. @cairolali
TICKET AGENT
WEEKLY SCHEDULE
<< work in progress>>
REQUESTED NUMBER
OF SEATS
AUDITORIUM PLAN
LIST OF AUDITORIUM
PLANS
SOLD SEATS
TICKETS
FILM SHOW
FOUND
SEATS
AUDITORIUM PLAN
WEEKLY SCHEDULE
<< finalized>>
FILM DISTRIBUTOR
CINEMA
MANAGER
AD
AGENCY ADVERTISMENT
BOOKING PLAN
PLAN FOR
FILM SHOWS
COUNTRYWIDE
NUMBER OF VISITORS
AVAILABILITY
OF FILMS
1
6
2
10
5
3
8
4
9
11
12
13
14
AUDITORIUM PLAN
15
STARTS
WORKING ON
CHECKS THE
NEGOTIATES
WITH
FINALIZES
THE
AND CREATES FOR
THE UPCOMMING
WEEK
MONEY TICKETS
TICKETS
ASKS FOR
FOR A
OPENS A
CLOSES THE
FROM THE
OFFERS
TO GIVES
TO
SEARCHES
ON
THE
ON
THE
MARKS
PRINTS
GIVES THE
TO
THE
Trigger
Trigger
once a week
each time a
customer asks
for a ticket
Cinema management
Ticket sales
CUSTOMER
7
In large cinemas, there are often also departments for these two sub-processes: <lick>
cinema management and <klick> ticket sales.
35

35. @cairolali
TICKET AGENT
WEEKLY SCHEDULE
<< work in progress>>
REQUESTED NUMBER
OF SEATS
AUDITORIUM PLAN
LIST OF AUDITORIUM
PLANS
SOLD SEATS
TICKETS
FILM SHOW
FOUND
SEATS
AUDITORIUM PLAN
WEEKLY SCHEDULE
<< finalized>>
FILM DISTRIBUTOR
CINEMA
MANAGER
AD
AGENCY ADVERTISMENT
BOOKING PLAN
PLAN FOR
FILM SHOWS
COUNTRYWIDE
NUMBER OF VISITORS
AVAILABILITY
OF FILMS
1
6
2
10
5
3
8
4
9
11
12
13
14
AUDITORIUM PLAN
15
STARTS
WORKING ON
CHECKS THE
NEGOTIATES
WITH
FINALIZES
THE
AND CREATES FOR
THE UPCOMMING
WEEK
MONEY TICKETS
TICKETS
FOR A
OPENS A
CLOSES THE
FROM THE
OFFERS
TO GIVES
TO
SEARCHES
ON
THE
ON
THE
MARKS
PRINTS
GIVES THE
TO
THE
Trigger
Trigger
once a week
each time a
customer asks
for a ticket
Cinema management
Ticket sales
information flow
CUSTOMER
7
The next very important indicator is found in the middle. When the left sub-process is
over, there is a <klick> flow of information in one direction into the other sub-process
and it continues there with ticket sales. a way back is not possible. this is a very strong
indicator of a boundary between two subdomains. The work in one subdomain is done
and the result is passed to another subdomain. In the second subdomain, work is
continued on the result or with the result. Finally, you can use this example to make
another point from DDD clear.
36

36. @cairolali
TICKET AGENT
WEEKLY SCHEDULE
<< work in progress>>
REQUESTED NUMBER
OF SEATS
AUDITORIUM PLAN
LIST OF AUDITORIUM
PLANS
SOLD SEATS
TICKETS
FILM SHOW
FOUND
SEATS
AUDITORIUM PLAN
WEEKLY SCHEDULE
<< finalized>>
FILM DISTRIBUTOR
CINEMA
MANAGER
AD
AGENCY ADVERTISMENT
BOOKING PLAN
PLAN FOR
FILM SHOWS
COUNTRYWIDE
NUMBER OF VISITORS
AVAILABILITY
OF FILMS
1
6
2
10
5
3
8
4
9
11
12
13
14
AUDITORIUM PLAN
15
STARTS
WORKING ON
CHECKS THE
NEGOTIATES
WITH
FINALIZES
THE
AND CREATES FOR
THE UPCOMMING
WEEK
MONEY TICKETS
TICKETS
ASKS FOR
FOR A
OPENS A
CLOSES THE
FROM THE
OFFERS
TO GIVES
TO
SEARCHES
ON
THE
ON
THE
MARKS
PRINTS
GIVES THE
TO
THE
Trigger
Trigger
once a week
each time a
customer asks
for a ticket
Cinema management
Ticket sales
information flow
WEEKLY SCHEDULE
<< printed>>
CUSTOMER
7
DDD assumes that terms in different subdomains can mean different things. We can also
imagine that here for our cinema. The customer looks at a <klick> weekly schedule to
find out about the planned film shows. This weekly schedule is much less detailed than
the <klick> weekly schedule that the cinema manager is working on. He noted the
cleaning times of the cinema halls and the ice cream seller and much more.
37

37. @cairolali
WeeklyPlanningService
• PlanFilmInHall
• AdPlanningForFilm
• ExpectedNumVisitors
• GenerateFinalSchedule
TicketSaleService
• SearchTimeForFilm
• SearchSeatsInHall
• BookSeats
• SellPlaces
UI WeeklyPlanning UI TicketSales UI WeeklyPlanning UI TicketSales
WeeklyScheduleService
• SearchTimeForFilm
• PlanFilmInHall
• AdPlanningForFilm
• ExpectedNumVisitors
• GenerateFinalSchedule
AuditoriumPlanService
• SearchSeatsInHall
• BookSeats
• SellPlaces
• GeneratePlans
Bounded Context
Cinema Management
Bounded Context
TicketSales
Service Weekly Schedule Service Auditorium Plans
Service
Tickets
Division according to entities
with direct coupling
Bounded contexts according to business
processes with "asynchronous" coupling
WeeklySchedule WeeklySchedule
WeeklySchedule
WeeklySchedule
AuditoriumPlans AuditoriumPlans
AuditoriumPlans
AuditoriumPlans
Ticket
Ticket
In a good solution we would have two bounded contexts: <klick> Cinema Manager and
<klick> Ticket Sales. The bounded context Cinema Manager would provide a <klick>
UserInterface for scheduling the weekly schedule. This user interface works on <klick> a
service that allows you to schedule movies in theaters, schedule advertising for movies
and more. The service itself uses <klick> the weekly schedule and auditoriums plans to
do its work.
The bounded context Ticket Sales would provide a <klick> User interface for ticket sales.
It works on <klick> a Service that allows you to search for films and halls and book and
sell tickets. The service itself uses <klick> the wekly schedule, the autotorium plans and
the ticket.
To communicate with each other the tow bounded contexts exchange <klick> the
weekly schedule and the auditorium plans. But this <klick> processing between the two
bounded contexts is done asynchronously. They don’t depend on each other.
A bad solution would be to divide the <klick> domain according to the entities involved
in the processes. Here we will need direct coupling. In this solution we would have
<klick> a Service Weekly Schedule and a Service <klick> Auditorium Plans. One service
for each Entity. Both entities would be protected by <klick> Services at their interface
the methods that are necessary to process the respective entity. Because the methods
are now each assigned to the service for the entity, at least the <klick> Ticket Sales user
interface must work synchronously with both services. In addition, there must be <click>
another service for the tickets. Comparing these two solutions, we see loosely coupled
bounded contexts on the left green side and strongly coupled system parts on the right
red side. DDD recommends us to go the left green way. If you go the left green way, you
have to live with the fact that you have the same entities in different bounded contexts.
the Weekly Schedule is present in both contexts.
But what is with reuse!
38

38. @cairolali
HOW DO I CUT MY LEGACY TO FIT THE DOMAIN?
▪ According to boundaries in the business process described by the domain experts
▪ Information flow
▪ Process rhythms
▪ Process triggers
▪ According to differences in the
use/definition of key concepts in the domain
▪ By departments in the organization or
groups of domain experts
Let's summarize: we can cut the domain into subdomains<klick> according to
boundaries in the business process. Good indicators are: <klick> the Information flow,
<klick> the process rythmes or <klick> the process triggers. We can cut the domain
<klick> according to differences in the use or definition of key concepts in the domain or
<klick> by departments in the organization or groups of domain experts.
https://commons.wikimedia.org/wiki/File:Beef_(PSF).jpg
39

39. @cairolali
612.869 LOC
14.756.435 LOC
252.062 LOC
804.093 LOC
543.388 LOC
1.035.668 LOC
486.358 LOC
175.258 LOC
42.311 LOC
193.383 LOC
643.466 LOC
245.754 LOC
2.890.204 LOC
141.696 LOC
512.086 LOC
9.988.363 LOC
200.591 LOC
922.949 LOC
22.658 LOC
663.862 LOC
3.270.188 LOC
1.521.357 LOC
0
2
4
6
8
10
MODULARITY MATURITY INDEX (MMI)
If you want to know how modular your source code is whether it is microservices or
monolith, we can measure this with the modularity maturity index. if modularity is
poor<klick>, the system is rated 0 to 4. If the modularity is not good but not too bad as
well <klick>, we give 4-8 as grade. If the modularity is good <klick>, the system gets 8-
10. The x axes represents just the time.
<klick>now you see different circles, each of which stands for a system. 22 systems in
different programming languages.
<klick>This system was built in Java, has 14 Mio and is very modular, <klick> this one is
as well Java but very bad modularity and <klick> this one is also Java with some
modularity but not enough to arrive in the green area, But this one <kick> is C# and
<klick> this one too. You see, the programming language has little influence on
modularity unfortunately. Us, the developers and architects, have to take care of it
ourselves!
How do we get to these rating:
40

40. @cairolali
ANALYSING MODULARITY WITH TOOLS
Structure101
Sotograph
Lattix
TeamScale
Sonargraph
we meet with our clients and analyse their systems for modularity with tools. The result
is the MMI. Since March 2020 our meetings are virtual of course.
41

41. @cairolali
@cairolali
cl@wps.de
www.sustainable-software-architecture.com
THANK YOU FOR YOUR ATTENTION!
If you want to know more about sustainable software architecture and Domain driven
Design, contact me per email or on twitter. Thank you for your attention.
42