The Presentation at Software Craftsmanship Turkey Meetup

1. Domain Driven Design
&
Hexagonal Architecture
Handling Complex Business Logic
Can Pekdemir

2. About me
Expert Software Engineer @iyzico
Dokuz Eylul University – Computer Science – 2010
Worked as consultancy in various domains like finance, e-commerce, telecom
Speaking at meetups rarely

3. The term
Domain Driven Design:
Tackling Complexity in the Heart of Software,
Eric Evans, 2003

4. Our Biggest Problems
Growing Complexity
Time to Market

5. General problems in sw development
Thinking software development as a cost center rather than a profit center
Heavy usage of the latest sexy framework all cool kids talk about
Poor collaboration with the business
Not giving real emphasis to naming things
Wrong abstractions and generalizing solutions unnecessarily by thinking
about 5 years later

6. Domain Driven Design
An approach for solving complex business problems
A mindset of developing business not only software
Helps team organization, enterprise architecture, code design
Cope with technology challenges ( e.g. Enterprise frameworks, NoSql,
Microservices)

7. Big ball of mud

8. Exploring the domain with
collaboration

9. Hands-on Modelers
People who write the code should feel responsible for the model.
A modeler should not be separated from implementation.

10. Ubiquitous Language
One team, one language
No need for translation
Use in both communication and in the code

11. Bounded Context
A semantic contextual boundary
Divide large system into autonomous contexts
Be explicit about the context responsibilities
Set boundaries and relationships with each other
Care about team organization, code bases, database schemas

12. Make sense of Bounded Contexts for
your company

13. Strategic Design with Bounded Context
Started as a monolithic application
More teams operated on the same application
Ownership began to blur
Shared resources were making it difficult to scale-out
“the traditional model is that you take your software to the wall that
separates development and operations, and throw it over and then forget
about it. Not at Amazon. You build it, you run it.”
Werner Vogels, CTO, Amazon, 2006
http://queue.acm.org/detail.cfm?id=1142065

14. Real Numbers
Over 6000 employees
In 400 cities and 70 countries
From 200 engineers to 2000 Engineers only in a year and half
8000 git repositories
Over 1000 microservices
https://www.youtube.com/watch?v=kb-m2fasdDY
What I Wish I Had Known Before Scaling Uber to 1000 Services - Matt
Ranney
“Scaling the traffic is not the issue. Scaling the team and the product feature
release rate is the primary driver.”

15. Context Mapping
• Strategic domain driven design
• Very useful tool to understand overall architecture and relationships of the
system.

16. Relations of Bounded Contexts

17. Anti Corruption Layers
Protect your own domain from the dependent contexts
Translate unrelated namings into your own domain
Protect yourself from others’ failures with timeouts and circuit breakers

18. Integrate Bounded Contexts with
Restful API
See your API from the consumer’s eyes
Do not reflect your entities to restful resources directly
Use consumer driven contract libraries ( e.g. PACT, Spring Cloud Contracts )

19. Integrate Bounded Contexts with
Messaging
Design your domain events regarding your business logic
Use at-least-once delivery messaging mechanism
Be careful about your receivers to idempotent

20. Aggregates
Compose entities and value objects and mark one entity as root
Apply consistency boundaries within aggregates
Modify and commit only one aggregate instance in one transaction
Hint for microservices

21. Aggregates (2)

22. Aggregate Design Rules
Do not let your business logic inside an aggregate leak
Design small aggregates
Reference by identity only
Update other aggregates by eventual consistency ( optional for scalability )

23. Domain Events
A record of some business-significant occurence in bounded context
Append-only event store mechanisms can be implemented

24. Organize your Code
Baklava Code
Code with too many layers

25. Hexagonal Architecture
Technology free Domain Model
“Allow an application to equally be driven by users, programs, automated test
or batch scripts, and to be developed and tested in isolation from its eventual
run-time devices and databases.” Alistair Cockburn – 2005
Decide on what is inside and outside

26. Benefits
Abstracts your business code from technical frameworks
Helps you to change your architectural decisions easily
Helps doing BDD and TDD

27. Packaging
Styles

28. Code time

29. References
Books
- Domain Driven Design: Tackling Complexity in the Heart of Software
- Domain Driven Design Distilled
- Implementing Domain Driven Design
- Building Microservices
Links
- http://www.codingthearchitecture.com/2016/04/25/layers_hexagons_features_and_components.html
- http://alistair.cockburn.us/Hexagonal+architecture
- https://www.johndcook.com/blog/2009/07/27/baklav-code/