1.
Tackling Complexity in the Heart of Software
Domain-Driven Design
카페서비스개발팀
조영호

2.
2. What is Domain-Driven Design?
3. Patterns of Domain-Driven Design
목차
4. Conclusion
1. Domain & Software

3.
1. Domain & Software

4.
4 / 문서의 제목
Domain-Driven Design - Book
By Eric Evans
Addison-Wesley, 2003

5.
5 / 문서의 제목
Domain & Software
The subject area to which the user
applies a program is the domain of
the software.
The critical complexity of most
software projects is in
understanding the domain itself.

6.
6 / 문서의 제목
Domain & Software
Software has to
Model the Domain

7.
7 / 문서의 제목
But...
Spring
ORM
Dependency Injection
Database
J2EE
Ajax
Continuous Integration
Hadoop
Coarse Grained Lock
Strategy
Hibernate
Mockito
ActiveMQ
RoRGrailsAOP
Naked Object

8.
8 / 문서의 제목
Cargo
cargoid
originid
destination
customers clearance(opt)
weight
Haz Mat Code
Routing Service
Database table : cargo_bookings
Cargo_id Transport Load Unload
origin
destination
customers clearance (opt)
populate cargo_bookings
table
"If we give the Routing Service an origin, destination, and arrival time, it
can look up the stops the cargo will have to make and, well . . . stick them
in the database."
Conversation Based on Technology

9.
2. What is Domain-Driven Design?

10.
10 / 문서의 제목
Representation[Semantic] Gap
The gap between our mental model of the domain and
its representation in software
Low Representation Gap
Name from domain vocabulary
Responsibility derived from
domain concept
LionCat

11.
11 / 문서의 제목
Ice Age of EJB
Cat
High
Representation Gap
<<interface>>
CatHome
<<interface>>
Cat
CatEJB
<<interface>>
EJBHome
<<interface>>
EJBObject
<<interface>>
EntityBean
Domain Concept
Design

12.
12 / 문서의 제목
Technology Exodus
OO design is more important
than any particular
implementation technology
(such as J2EE, or even Java).
And now important than
even Spring or Hibernate

13.
13 / 문서의 제목
DOMAIN MODEL Pattern
An object model of the domain that
incorporates both behavior and data.
Sale
getTotalPrice() : long
setTotalPrice(long)
getLineItems() : Collection
setLineImtes(Collection)
LineItem
getPrice() : long
setPrice(long)
getPrioduct() : Product
setProduct(Product)
Sale
calclulatePrice() : Money
addLineItem(LineItem)
LineItem
calculatePrice() : long
*
TRANSACTION SCRIPT &
ANEMIC DOMAIN MODEL RICH DOMAIN MODEL
Back to the Origin of the OO

14.
14 / 문서의 제목
Continuous Design in Agile
Specification
Test
Design
Code
Big Up-front
Design
Incremental
Design
Refactoring

15.
15 / 문서의 제목
Analysis = Design = Implementation
Analysis Model
seatId
ReservationSeat
Showing
time
Design Model
seatId
ReservationSeat
Showing
time : TimeOfDay
1
Implementation Model
Showing showing =
showingRepository.getShowingWithLock(showingId);
Reservation reservation =
showing.reserveSeats(seatIds,
adultSeatCount, teenagerSeatCount);
reservationRepository.saveReservation(reservation);

16.
16 / 문서의 제목
And Finally
Focus on Domain Complexity,
not Technology Complexity
Everything is Driven By Domain

17.
17 / 문서의 제목
And Finally
Tackling Complexity
in the Heart of Software

18.
18 / 문서의 제목
And Finally
UBIQUITOUS LANGUAGE
MODEL-DRIVEN DESIGN

19.
19 / 문서의 제목
Model

20.
20 / 문서의 제목
Model
A system of abstractions that describes
selected aspects of a domain and
can be used to solve problems related
to that domain
A model is not right or wrong, only more or
less useful

21.
21 / 문서의 제목
Domain Modeling
Documentary Film
A domain modeler chooses particular model for usability

22.
22 / 문서의 제목
Model & Diagram
A Domain Model is not a particular diagram.
It is the knowledge that the diagram is
intended to convey.
The Diagram is a representation of Model
Not a Model

23.
23 / 문서의 제목
Model-Driven Design

24.
24 / 문서의 제목
The MODEL and the heart of the DESIGN
shape each other
Model-Driven Design
DOMAIN
MODEL
seatId
ReservationSeat
Showing
time
DESIGN
seatId
ReservationSeat
Showing
time : TimeOfDay
1
CODE
Showing showing =
showingRepository.getShowingWithLock(showingId);
Reservation reservation =
showing.reserveSeats(seatIds,
adultSeatCount, teenagerSeatCount);
reservationRepository.saveReservation(reservation);

25.
25 / 문서의 제목
Find the Model that works for Analysis, Design
and Implementation
Model-Driven Design
Lower Representation Gap
Object-Oriented Paradigm is the most Powerful
The Code is an expression of Model

26.
26 / 문서의 제목
A Programmer is a Modeler.
Hands-On Modelers

27.
27 / 문서의 제목
UBIQUITOUS LANGUAGE

28.
28 / 문서의 제목
UBIQUITOUS LANGUAGE
Conversations among
Developers
Discussions among
Domain Experts
Expressions
in the Code
Discussion between
Developers and
Domain Experts
All based on the same language,
derived from a shared Domain Model

29.
29 / 문서의 제목
UBIQUITOUS LANGUAGE
technical
aspects of
design
technical terms
technical design
patterns
business terms
developers don’t
understand
business terms
everyone uses that
don’t appear in design
domain model terms
names of
BOUNDED CONTEXT
terminology of large-scale
structure
many patterns from
Domain-Driven Design book

30.
30 / 문서의 제목
Use the Domain Model as the backbone of a Language
UBIQUITOUS LANGUAGE
Use the same language in diagrams, writing, and especially
speech
Use the UBIQUITOUS LANGES in all communication within
team and in the code
One Team, One Language

31.
31 / 문서의 제목
And Domain-Driven Design
DOMAIN
MODEL
seatId
ReservationSeat
Showing
time
UBIQUITOUS
LANGUAGE
Showing
Reservation
Reservation Seat
CODE
Showing showing =
showingRepository.getShowingWithLock(showingId);
Reservation reservation =
showing.reserveSeats(seatIds,
adultSeatCount, teenagerSeatCount);
reservationRepository.saveReservation(reservation);

32.
32 / 문서의 제목
And Domain-Driven Design
DOMAIN
MODEL
seatId
ReservationSeat
Showing
time
UBIQUITOUS
LANGUAGE
Showing
Reservation
Reservation Seat
CODE
Showing showing =
showingRepository.getShowingWithLock(showingId);
Reservation reservation =
showing.reserveSeats(seatIds,
adultSeatCount, teenagerSeatCount);
reservationRepository.saveReservation(reservation);

33.
33 / 문서의 제목
And Domain-Driven Design
DOMAIN
MODEL
seatId
ReservationSeat
Showing
time
UBIQUITOUS
LANGUAGE
Performance
Reservation
Reservation Seat
CODE
Showing showing =
showingRepository.getShowingWithLock(showingId);
Reservation reservation =
showing.reserveSeats(seatIds,
adultSeatCount, teenagerSeatCount);
reservationRepository.saveReservation(reservation);

34.
34 / 문서의 제목
And Domain-Driven Design
DOMAIN
MODEL
seatId
ReservationSeat
Performance
time
UBIQUITOUS
LANGUAGE
Performance
Reservation
Reservation Seat
CODE
Showing showing =
showingRepository.getShowingWithLock(showingId);
Reservation reservation =
showing.reserveSeats(seatIds,
adultSeatCount, teenagerSeatCount);
reservationRepository.saveReservation(reservation);

35.
35 / 문서의 제목
And Domain-Driven Design
DOMAIN
MODEL
seatId
ReservationSeat
Performance
time
UBIQUITOUS
LANGUAGE
Performance
Reservation
Reservation Seat
CODE
Performance performance =
performanceRepository.getPerformanceWithLock(
performanceId);
Reservation reservation =
showing.reserveSeats(seatIds,
adultSeatCount, teenagerSeatCount);
reservationRepository.saveReservation(reservation);

36.
36 / 문서의 제목
And Domain-Driven Design
A Showing is...

37.
37 / 문서의 제목
And Domain-Driven Design
A Performance is...

38.
38 / 문서의 제목
Cargo
cargoid
originid
destination
customers clearance(opt)
weight
Haz Mat Code
Routing Service
Database table : cargo_bookings
Cargo_id Transport Load Unload
origin
destination
customers clearance (opt)
populate cargo_bookings
table
"If we give the Routing Service an origin, destination, and arrival time, it
can look up the stops the cargo will have to make and, well . . . stick them
in the database."
Conversation Based on Technology

39.
39 / 문서의 제목
Cargo
cargoid
weight
Haz Mat Code
Routing Service
Route Specification
origin
destination
customers clearance (opt)
Itinerary
Leg
0..1
{Itinerary must satisfy specification}
a Route Specification
an Itinerary satisfying
the Route Specification
"A Routing Service finds an Itinerary that satisfies a Route Specification.”
Conversation Based on Model

40.
3. Patterns of Domain-Driven Design

41.
41 / 문서의 제목
Domain-Driven Design & Patterns
DDD is not about patterns such as ENTITY, VALUE OBJECT,
AGGREGATE, REPOSITORY, SERVICE, FACTORY
DDD is a better way of thinking about software design
Patterns may take your software more stable or more maintainable,
but it is the methodology that guides you to deliver something fit
for purpose

42.
42 / 문서의 제목
DOMAIN MODEL is a King

43.
43 / 문서의 제목
A King, DOMAN MODEL is RICH, Not ANEMIC
<<interface>>
ShowingRepository
getShowingWithLock(showingId) :Showing
seatId
<<interface>>
SeatState
AbstractSeatState
Reserved
1
0..1
1
0..*
1
0..1
leftSeat
0..1
rightSeat
0..1
nextSeatState
0..1
previousSeatState
<<interface>>
ScheduleService
reserve(showingId, seats,adultSeatCount, teenagerSeatCount) : Reservation
ReservationSeat
-showingRepository -reservationRepository
ScheduleServiceImpl
Occupied Sold
<<interface>>
ReservationRepository
saveReservation(reservation)
ShowingFactory
create(dayOfYear, showingSpecification) : Showing
Showing
time:TimeOfYear
Reservation
amount:Money

44.
44 / 문서의 제목
<<interface>>
ShowingRepository
getShowingWithLock(showingId) :Showing
seatId
<<interface>>
SeatState
AbstractSeatState
Reserved
1
0..1
1
0..*
1
0..1
leftSeat
0..1
rightSeat
0..1
nextSeatState
0..1
previousSeatState
<<interface>>
ScheduleService
reserve(showingId, seats,adultSeatCount, teenagerSeatCount) : Reservation
ReservationSeat
-showingRepository -reservationRepository
ScheduleServiceImpl
Occupied Sold
<<interface>>
ReservationRepository
saveReservation(reservation)
ShowingFactory
create(dayOfYear, showingSpecification) : Showing
Showing
time:TimeOfYear
Reservation
amount:Money
A King, DOMAN MODEL is RICH, Not ANEMIC
SERVICE
ENTITY
AGGREGATE
VALUE
OBJECT
REPOSITORY
FACTORY

45.
45 / 문서의 제목
A King should be Protected

46.
46 / 문서의 제목
Layered Architecture
User Interface
Application
Domain
Infrastructure

47.
47 / 문서의 제목
CONTEXT is a King’s Domain

48.
48 / 문서의 제목
BOUNDED CONTEXT

49.
49 / 문서의 제목
BOUNDED CONTEXT
Model
Model
CONTEXT
CONTEXT

50.
50 / 문서의 제목
Translate two UBIQUATIOUS LABUAGES

51.
51 / 문서의 제목
CONTEXT MAP
Model
Model
CONTEXT
CONTEXT
TRNSLATION MAP

52.
52 / 문서의 제목
CONTINUOUS INTEGRATION
Model
Model
CONTEXT
CONTEXT
CONTINUOUS INTEGRATION per each CONTEXT

53.
53 / 문서의 제목
A king should learn continuously

54.
54 / 문서의 제목
DISTILLATION
User Interface
Application
Infrastructure
Domain
CORE
DOMAIN
GENERIC
SUBDOMAIIN
COHESIVE
MECHANISM
SEGREGATED
CORE
ABSTRACT
CORE
Refactoring

55.
55 / 문서의 제목
CONTEXT & MODEL
No duplication...within a context!
Model
Model
CONTEXT
CONTEXT
Single, Unified Model within Any One Context
Duplication between...AOK!

56.
4. Conclusion

57.
57 / 문서의 제목
No Silver Bullet

58.
58 / 문서의 제목
Essence of Software
Complexity Conformity
Changeability Invisibility

59.
59 / 문서의 제목
Essence of Software
Complexity Conformity
Changeability Invisibility
Related to
Domain & Domain Model

60.
60 / 문서의 제목
Domain-Drive Design
Back to the Basics
Software should model the Domain
Software & Project should be based on the Domain Model
Software that provides rich functionality based on a
fundamental understanding of the core domain
Tackling Essence
in the Heart of Software

61.
61 / 문서의 제목
But Remember... No Silver Bullet

62.
62 / 문서의 제목
Resources
- Domain-Driven Design, Eric Evans, Addison-Wesley, 2003
- Patterns of Enterprise Application Architecture, Martin Fowler, Addison-Wesley,
2002
- Applying Domain-Driven Design and Patterns, Jimmy Nilson, Addison-Wesley,
2006
- Domain Driven Design Quickly, http://www.infoq.com/minibooks/domain-driven-
design-quickly
- Domain-Driven Design Step-By-Step, http://dddstepbystep.com/cfs-
filesystemfile.ashx/__key/CommunityServer.Components.SiteFiles/Domain-Driven-
Design-_2D00_-Step-by-Step.pdf
- Domain-Driven Design Community, http://domaindrivendesign.org/
- Eternity’s Chit-Chat, http://aeternum.egloos.com/

63.
Thank you.

64.
Question.