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
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
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
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
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
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
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
55. 55 / 문서의 제목
CONTEXT & MODEL
No duplication...within a context!
Model
Model
CONTEXT
CONTEXT
Single, Unified Model within Any One Context
Duplication between...AOK!
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