The document discusses Domain-Driven Design (DDD) and Behavior-Driven Development (BDD) and how they help reduce translation costs. It notes that having different languages used by domain experts and technical teams can cause problems. Both DDD and BDD aim to develop a shared "ubiquitous language" to facilitate conversations and ensure the technical solution matches the business needs. DDD uses domain models in code while BDD uses scenarios to represent the domain model and check features help rather than harm businesses.

1. DDD
for not developers

2. IT'S ABOUT
LANGUAGE MONEY

3. –Eric Evans, Domain-Driven Design
“A project faces serious problems when its language is
fractured. Domain experts use their jargon while
technical team members have their own.”

8. Incorrect translations are the primary cause of
features that damage business instead of helping
them.
COST OFTRANSLATION

9. BDD & DDD

10. BDD focuses on eliminating translation costs on
conversations

16. BDD uses scenarios

17. –Eric Evans, Domain-Driven Design
“To cross-check all these decisions, we have to
constantly step through scenarios to confirm that we
can solve application problems effectively.”

18. DDD focuses on eliminating translation costs in
the code

22. DDD uses domain models

23. –Eric Evans, Domain-Driven Design
“A domain model is not a particular diagram; it is the
idea that the diagram is intended to convey.A diagram
can represent and communicate a model, as can
carefully written code, as can an English sentence.”

24. BDD & DDD help you to reduce the cost of
translations

25. UBIQUITOUS LANGUAGE

26. Helps you to facilitate conversations

27. Model your core domain in a language both business
and developers can understand.

28. DRIVINGTHE CORE DOMAIN

29. Embed Ubiquitous language into scenarios

30. Your scenarios become your domain model

31. These scenarios can be used to develop the core
domain

32. –Konstantin Kudryashov (@everzet)
“Focus on discussing business problems and the
architecture will emerge naturally.”

33. THANKS