The document discusses Domain-Driven Design (DDD), an approach to software development for complex domains. It covers DDD concepts like the domain, subdomain, bounded context, and ubiquitous language. It also discusses strategic DDD concepts and tactical implementations, including hexagonal architecture, entities, value objects, services, domain events, aggregates, factories, and repositories. The advantages of DDD are clearer code, better domain understanding, and focus on the business domain. Disadvantages include a high upfront time cost and learning curve.

1. 1
Privalia
9 MARZO 2017

2. 2A LEADING GROUP AT YOUR SERVICE
LEADERS IN ALL MARKETS
POLAND
FRANCE, SPAIN, ITALY,
GERMANY, AUSTRIA, UK
SPAIN, ITALY, MEXICO,
BRAZIL
BENELUX
SWITZERLAND
DENMARK
Uncontestable flash sales
leader in Europe and
LATAM.
We are your partner to
deliver you a global
service tailored to each
market according to your
business needs.
VENTE-PRIVEE GROUP AMBITIONS

3. 3A LEADING GROUP AT YOUR SERVICE
FACTS & FIGURES
#1 Flash Sales in EU and
Latam.
#2 e-commerce in EU
MAJOR PLAYER
Members
+ 60 M
Products sold / day
+320 K
In 2016*
2,1€ Bn
Unique sales visitors
12,1M
Of sales from mobile
65%
* Classic Sales (w/out taxes)

4. 4A LEADING GROUP AT YOUR SERVICE
IT AREAS
# Systems # Production
# Cybersecurity # Network
# Application Maintenance
INFRASTRUCTURE
# SAP # WMS
# ETL # Data # Scrum
BACKOFFICE
CORE TEAM
QA & RELEASE BI & DATA PLATFORM AGILE OFFICE
# Mobile # Catalogue
# Customer # Payments &
Fraud # Billing & Interfaces
# Supply Chain # Marketplace
# VP Integration
# Architecture Solution
# QA # DevOps

5. 5A LEADING GROUP AT YOUR SERVICE
IT TECHNOLOGIES
DATA CODE TOOLS PERFORMANCE

6. 6A LEADING GROUP AT YOUR SERVICE
JOB OPPORTUNITIES
HIRING!
We are
01001010010011110100100101001110
# Tech Lead # PHP Developer # DevOps # Android Developer
# IOS Developer # Solutions Architect # Scrum Master # SAP FICO
# SAP LO # WMS JIT Developer # QA # JAVA Developer #Javascript
# CISO # ETL Developer # Systems Administrator
people@privalia.com
01001010010011110100100101001110

7. 7
From Legacy to
DDD in PHP
Tech Talk | Privalia
9 MARZO 2017

8. 8WHO I AM
Jordi Vila Gallardo
Senior Developer @Privalia
Twitter: @jordivilaga

9. 9
1. Legacy
2. Introduction (DDD)
3. Strategic (DDD)
- Concepts
4. Tactical (DDD)
- Architecture
- Layers
- Objects
5. Advantages and disadvantages
6. Demo
SUMMARY

10. 10
Legacy
1

11. 111. Legacy
Computer program (typically a database system) which, although critical to an organization's operations, is
in an obsolete format or is installed on an obsolete system.
● Not testable.
● Hard to maintain.
● Reduces performance.
● Security and access control problems.
● Reduces productivity.
● Hard to scale.
● Reduces time to market.

12. 12
Introduction
Domain-Driven Design
2

13. 132. Introduction
● Is an approach to software development for complex needs.
● It was coined by Eric Evans in his book “Domain-Driven Design - Tackling Complexity in the Heart of
Software”.
SOME PREMISES
● Primary focus on the domain logic.
● Initiating continuous collaboration between technical and domain experts.
● Development based on business and not database oriented.

14. 142. Introduction
STRATEGIC VS TACTICAL
STRATEGIC VS TACTICAL
Domain-Driven Design

15. 15
STRATEGIC
Domain-Driven Design
3

16. 163. Strategic
● Domain
● Subdomain
● Bounded Context
● Ubiquitous Language
CONCEPTS

17. 173. Strategic
DOMAIN
Is the global problem space.

18. 183. Strategic
SUBDOMAINS
Are a portion of the problem space concept.

19. 193. Strategic
BOUNDED CONTEXT
Are a portion of the solution space concept. In other words, the subdomain is describing something
about the way you’ve chosen to break down your business and the bonded context describes how the
software has been broken down.

20. 203. Strategic
DOMAIN EXPERT
A member of a software project whose field is the domain of the application, rather than software
development. Not just any user of the software, the domain expert has deep knowledge of the subject.

21. 213. Strategic
UBIQUITOUS LANGUAGE
Ubiquitous language is the term Eric Evans in Domain-Driven Design for the practice of building up
common, rigorous language between developers and users. This language should be based on the
Domain Model used in the software.

22. 223. Strategic
● Learning about our Domain by talking with a Domain Expert.
● Breaking the Domain into Subdomains.
● Focusing on one Subdomain with the Domain Expert.
○ Make a list of things we need to know about the Subdomain.
○ Modeling the Domain with the Domain Expert and working the terminology.
● First high-level Model of the Subdomain.
STEPS TO MODELING A PROBLEM IN SOFTWARE

23. 23
TACTICAL
Domain-Driven Design
4

24. 244. Tactical
● Hexagonal Architecture
● CQRS (Command-Query Responsibility Segregation)
● Event-Driven Architecture
● Service-Oriented
● Representational State Transfer (REST)
● Data Fabric and Grid-Based Distributed Computing
ARCHITECTURES

25. 254. Tactical
HEXAGONAL ARCHITECTURE

26. 264. Tactical
LAYERS
CONTROLLERS
COMMANDS
USE CASES
DTO’S
ENTITIES
VALUE
OBJECTS
LOGGING
EXCEPTIONS
DOMAIN
EVENTS
REPOSITORIES

27. 274. Tactical
● Entities → Domain
● Value Objects → Domain
● Services → Domain, Infrastructure and Application
● Domain Events → Domain
● Aggregates → Domain
● Factories → Domain
● Repositories → Infrastructure
OBJECTS

28. 284. Tactical
OBJECTS: ENTITIES
An object fundamentally defined by identity and not by its attributes.
CHARACTERISTICS
● Unique identity.
● Mutable.
● Comparison using identifier or reference equality.
● Can live by its own.
● Lifespan (It has history of what happened to it and how it changed during its lifetime).

29. 294. Tactical
OBJECTS: ENTITIES - ANEMIC ENTITY ANTI-PATTERN
ANEMIC NON ANEMIC

30. 304. Tactical
OBJECTS: ENTITIES - UBIQUITOUS LANGUAGE
UBIQUITOUS LANGUAGE
Modeling on terms coming out of our UBIQUITOUS LANGUAGE instead of a noun and verbs
object-oriented design.
Traditional object-oriented design: UBIQUITOUS LANGUAGE design:

31. 314. Tactical
OBJECTS: VALUE OBJECTS
An object that contains attributes but has not conceptual identity.
CHARACTERISTICS
● Measures, quantifies, or describe a thing in the domain.
● Immutable
● Comparison using structural or reference equality.
● Can not live by its own, it should always belong to one or several entities.
● No lifespan.

32. 324. Tactical
OBJECTS: VALUE OBJECTS - EXAMPLE
EXAMPLE: Example of Value Object.

33. 334. Tactical
OBJECTS: VALUE OBJECTS - EXAMPLE IMMUTABILITY
EXAMPLE: Immutability
Money constructor Increase the amount

34. 344. Tactical
OBJECTS: SERVICES
It’s a middleware between the outside world and the domain logic.
CHARACTERISTICS
● The operation relates to a domain concept that is not a natural part of an ENTITY or VALUE OBJECT.
● The operation name is part of the UBIQUITOUS LANGUAGE.
● The operation is stateless.

35. 354. Tactical
OBJECTS: SERVICES
TYPES
● Application Services
○ Is how the outside world communicates with our application.
○ This could be through HTTP requests, an API or through an automated messaging service.
○ Business rules are not allowed.
○ Sometimes referred as “Workflow Services” or “Use Cases”.
● Domain Services
○ Encapsulates business logic that does not naturally fit within a domain objects.
○ Meaning and responsibilities should make sense to the STAKEHOLDERS or DOMAIN EXPERTS.
● Infrastructure Services
○ Is used for dealing with technical details of the infrastructure.

36. 364. Tactical
OBJECTS: SERVICES
DOMAIN SERVICE
EXAMPLE: Hashing service.
● Is derived from the UBIQUITOUS LANGUAGE? Yes
● Is stateless? Yes
● Is it not responsibility of any existing domain object? Yes
Then I would say that is an excellent candidate for a DOMAIN SERVICE.

37. 374. Tactical
OBJECTS: SERVICES
INFRASTRUCTURE SERVICE
EXAMPLE: Hashing service implementation.
● Is the implementation derived from the UBIQUITOUS LANGUAGE? No
● Is important how the password is actually hashed? No
Then I would say the implementation of hashing a password would go inside an INFRASTRUCTURE
SERVICE.

38. 384. Tactical
OBJECTS: DOMAIN EVENTS
Use a DOMAIN EVENT to capture an occurrence of something that happened in the domain.

39. 394. Tactical
OBJECTS: AGGREGATES
A collection of objects that are bound together by a root entity, otherwise known as an aggregate root.

40. 404. Tactical
OBJECTS: AGGREGATES
EXAMPLE: Example on how to create a new address in a customer entity.

41. 414. Tactical
OBJECTS: FACTORIES
A pattern design for decoupling the client from the knowing how to build a complex objects and
aggregates.

42. 424. Tactical
OBJECTS: FACTORIES
EXAMPLE: Product factory.

43. 434. Tactical
OBJECTS: REPOSITORIES
It’s a structural design pattern that mediates between the domain and data mapping layers using
collection-like interface for accessing domain objects.

44. 44
Advantages and
disadvantages
5

45. 455. Advantages
● Give us the principles and patterns to solve difficult problems.
● History of success.
● Clear code.
● Better understanding.
● Interaction with Domain Experts.
● Focus on the Domain.

46. 465. Disadvantages
● Only for complex domains.
● Time consuming upfront.
● High learning curve.

47. 475. References
● Wikipedia: https://en.wikipedia.org/wiki/Domain-driven_design
● Books: Implementing Domain-Driven Design by Vaughn Vernon and Domain-Driven Design in PHP
by Carlos Buenosvinos, Christian Soronellas, and Keyvan Akbary.

48. 48
DEMO
6

49. 49