Are you working with an existing codebase? Do you want to use the cool libraries, tools or methodology you saw at this conference? This talk will show you how to combine legacy code with bleeding edge technology. Often the use of new technology and protocols is limited by fear of change in existing applications. Yet, as developers, we want to remain relevant and have fun with all the disruptive changes in our industry. This talk will drill-down from a high-level architectural view to the actual implementation of modern, strangling services in a legacy monolith, using DDD to define bounded contexts, in a safe and controlled manner.

1. @DaggieBe#DevoxxPL
Platinum Sponsor:
Innovation Without Asking
Permission
Bart Blommaerts
BB Consulting

2. bbconsulting.be
Bart Blommaerts
Application Architect
BB Consulting
@DaggieBe

3. 3
Blockchain DeepLearning
Serverless Reactive
Software development is awesome

4. 4
Chained Learned nothing
ServerError Radioactive
Legacy applications …

5. Observation: There's a colossal gap
between a lot of solutions presented at
conferences and the kinds of problems
many folks are actually trying to solve.
Robert Smallshire (@robsmallshire)

6. 1. Service Decomposition

7. Service Decomposition
Three Approaches
to Moving From a
Large Monolith to
Smaller Services
Strangle
Extract and re-implement.
Extend
Prevent the monolith from becoming
larger.
Split
Focus on data. Look for high cohesion
and low-coupling.
@DaggieBe

8. • Conduct a dependency analysis
• Focus on the data
• Split off one by one and validate
• Learn and refine
Split
@DaggieBe

9. • Existing functionality is extracted
and re-implemented
• Use an Anti Corruption Layer for decoupling
• Make the monolith smaller
Strangle
@DaggieBe

10. • Minimise impact on the existing application
• Implement new features as separate services
• Use an Anti Corruption Layer for decoupling
• Prevent the monolith from growing
Extend
@DaggieBe

11. You do not need
to stick to a
single approach.

12. Anti-Corruption Layer
Decouple domain models
Enforce bounded contexts
Focus on good APIs
Translate to / from different models

13. Anti-Corruption Layer
Deal with data access:
- Shared repository
- Data synchronised repository
- Event-Driven synchronised repository
@DaggieBe

14. Shared Repository
@DaggieBe

15. Shared Repository
@DaggieBe

16. Shared Repository
@DaggieBe

17. Data Synchronised Repository
@DaggieBe

18. Event-Driven Synchronised Repository
@DaggieBe

19. What is an event?
Something that has happened in the past.
Types of data
An event can
contain 3 types of
data
data it owns
data it needs
reference data
@DaggieBe

20. 2. Bounded Contexts

21. POSTAL SERVICES
@DaggieBe

22. Identify domains
Focus on business capability
BusinessCapability
Don’t focus on technology layer
TechnologyLayer
@DaggieBe

23. domain:
- mail delivery
sub domains:
- optimal route calculation
- geographical division
- product management
- people
- constraints
- …
Identify bounded contexts
@DaggieBe

24. How?
Identify bounded contexts
@DaggieBe

25. Talk to business stakeholders
Identify bounded contexts
@DaggieBe

26. Look at the data
Identify bounded contexts
@DaggieBe

27. Look at the code
Identify bounded contexts
@DaggieBe

28. Between bounded contexts,
multiple integration patterns are possible
Identify bounded contexts
@DaggieBe

29. Domain decomposition
@DaggieBe

30. 3. Demo

31. Observation: There's a colossal gap
between a lot of solutions presented at
conferences and the kinds of problems
many folks are actually trying to solve.
Robert Smallshire (@robsmallshire)

32. 4. APIs

33. Examples:
- Paypal: https://developer.paypal.com/docs/api/
- Zalando: https://zalando.github.io/restful-api-guidelines/
- GitHub: https://developer.github.com/v3/
- Stripe: https://stripe.com/docs/api#intro
- Microsoft: https://github.com/Microsoft/api-guidelines/
- Travis: https://docs.travis-ci.com/api/
- Adidas: https://github.com/adidas-group/api-guidelines
- …
API Guidelines
@DaggieBe

34. Postel’s Law: Be conservative in what you
do, be liberal in what you accept from
others.
Jon Postel

35. Quickly repurpose top innovation
before global communities.
Documented API
Swagger
HAL
RAML
Avro Schemas
@DaggieBe

36. 5. Without asking permission?

37. Continuous Experimentation
Microservices enable experimentation
Feature toggles
Dynamically enable or disable features
Traffic routing
Route your traffic to your experiments
Data-driven decision making
Monitoring and telemetry to observe behaviour
@DaggieBe

38. Distributed systems are hard
Fallacies of distributed computing
Benefits
Loose coupling, enabling innovation, …
Drawbacks
Moving parts, transport, consistency, …
@DaggieBe

39. Maintenance
Microservices enable technology introduction
No free lunch
Dedicate time to technology selection
DevOps
End-to-end responsibility
@DaggieBe

40. Middleware
Runs on my machine …
Dependencies
Containers without orchestration?
Suitable infrastructure
Database, messaging bus, monitoring, …
@DaggieBe

41. GREG YOUNG - 5 common reasons DDD projects fail and how to avoid them
https://skillsmatter.com/skillscasts/1431-greg-young-ddd-projects
Sources
MARTIN FOWLER - Richardson Maturity Model
https://martinfowler.com/articles/richardsonMaturityModel.html
WIKIPEDIA - Fallacies of distributed computing
https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing
IEEE Software - Continuous Experimentation
https://ieeexplore.ieee.org/document/8255793/
DEMO - Postal Demo
https://github.com/bart-blommaerts/postal-demo
DEMO - Postal Calculator
https://github.com/bart-blommaerts/postal-calculator
@DaggieBe

42. Thank You
@DaggieBe