Domain Driven Design

2,852 views
2,714 views

Published on

NHN 재직 시에 "도메인 주도 설계" 관련해서 발표했던 자료입니다. 벌써 시간이 꽤 흘렀네요. ^^

Published in: Software
0 Comments
27 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,852
On SlideShare
0
From Embeds
0
Number of Embeds
764
Actions
Shares
0
Downloads
43
Comments
0
Likes
27
Embeds 0
No embeds

No notes for slide

Domain Driven Design

  1. 1. Tackling Complexity in the Heart of Software Domain-Driven Design 카페서비스개발팀 조영호
  2. 2. 2. What is Domain-Driven Design? 3. Patterns of Domain-Driven Design 목차 4. Conclusion 1. Domain & Software
  3. 3. 1. Domain & Software
  4. 4. 4 / 문서의 제목 Domain-Driven Design - Book By Eric Evans Addison-Wesley, 2003
  5. 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. 6 / 문서의 제목 Domain & Software Software has to Model the Domain
  7. 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. 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. 9. 2. What is Domain-Driven Design?
  10. 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. 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. 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. 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. 14 / 문서의 제목 Continuous Design in Agile Specification Test Design Code Big Up-front Design Incremental Design Refactoring
  15. 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. 16 / 문서의 제목 And Finally Focus on Domain Complexity, not Technology Complexity Everything is Driven By Domain
  17. 17. 17 / 문서의 제목 And Finally Tackling Complexity in the Heart of Software
  18. 18. 18 / 문서의 제목 And Finally UBIQUITOUS LANGUAGE MODEL-DRIVEN DESIGN
  19. 19. 19 / 문서의 제목 Model
  20. 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. 21 / 문서의 제목 Domain Modeling Documentary Film A domain modeler chooses particular model for usability
  22. 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. 23 / 문서의 제목 Model-Driven Design
  24. 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. 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. 26 / 문서의 제목 A Programmer is a Modeler. Hands-On Modelers
  27. 27. 27 / 문서의 제목 UBIQUITOUS LANGUAGE
  28. 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. 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. 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. 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. 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. 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. 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. 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. 36 / 문서의 제목 And Domain-Driven Design A Showing is...
  37. 37. 37 / 문서의 제목 And Domain-Driven Design A Performance is...
  38. 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. 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. 40. 3. Patterns of Domain-Driven Design
  41. 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. 42 / 문서의 제목 DOMAIN MODEL is a King
  43. 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. 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. 45 / 문서의 제목 A King should be Protected
  46. 46. 46 / 문서의 제목 Layered Architecture User Interface Application Domain Infrastructure
  47. 47. 47 / 문서의 제목 CONTEXT is a King’s Domain
  48. 48. 48 / 문서의 제목 BOUNDED CONTEXT
  49. 49. 49 / 문서의 제목 BOUNDED CONTEXT Model Model CONTEXT CONTEXT
  50. 50. 50 / 문서의 제목 Translate two UBIQUATIOUS LABUAGES
  51. 51. 51 / 문서의 제목 CONTEXT MAP Model Model CONTEXT CONTEXT TRNSLATION MAP
  52. 52. 52 / 문서의 제목 CONTINUOUS INTEGRATION Model Model CONTEXT CONTEXT CONTINUOUS INTEGRATION per each CONTEXT
  53. 53. 53 / 문서의 제목 A king should learn continuously
  54. 54. 54 / 문서의 제목 DISTILLATION User Interface Application Infrastructure Domain CORE DOMAIN GENERIC SUBDOMAIIN COHESIVE MECHANISM SEGREGATED CORE ABSTRACT CORE Refactoring
  55. 55. 55 / 문서의 제목 CONTEXT & MODEL No duplication...within a context! Model Model CONTEXT CONTEXT Single, Unified Model within Any One Context Duplication between...AOK!
  56. 56. 4. Conclusion
  57. 57. 57 / 문서의 제목 No Silver Bullet
  58. 58. 58 / 문서의 제목 Essence of Software Complexity Conformity Changeability Invisibility
  59. 59. 59 / 문서의 제목 Essence of Software Complexity Conformity Changeability Invisibility Related to Domain & Domain Model
  60. 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. 61 / 문서의 제목 But Remember... No Silver Bullet
  62. 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. 63. Thank you.
  64. 64. Question.

×