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

Size: px

Start display at page:

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

Eugene Lewis
5 years ago
Views:

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

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

3 1. Domain & Software

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

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. 5 / 문서의제목

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

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

Conversation Based on Technology Cargo cargoid originid destination customers clearance(opt) weight Haz Mat Code origin destination customers clearance (opt) Routing Service populate cargo_bookings

8 Conversation Based on Technology Cargo cargoid originid destination customers clearance(opt) weight Haz Mat Code origin destination customers clearance (opt) Routing Service populate cargo_bookings table Database table : cargo_bookings Cargo_id Transport Load Unload "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." 8 / 문서의제목

9 2. What is Domain-Driven Design?

Name from domain vocabulary Responsibility derived from

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

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

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 12 / 문서의제목

DOMAIN MODEL Pattern An object model of the domain that

Back to the Origin of the OO TRANSACTION SCRIPT & ANEMIC

settotalprice(long) getlineitems() : Collection

setprice(long) getprioduct() : Product setproduct(product)

13 DOMAIN MODEL Pattern An object model of the domain that incorporates both behavior and data. Back to the Origin of the OO TRANSACTION SCRIPT & ANEMIC DOMAIN MODEL Sale gettotalprice() : long settotalprice(long) getlineitems() : Collection setlineimtes(collection) LineItem getprice() : long setprice(long) getprioduct() : Product setproduct(product) RICH DOMAIN MODEL Sale calclulateprice() : Money addlineitem(lineitem) * LineItem calculateprice() : long 13 / 문서의제목

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

Analysis = Design = Implementation Showing time seatid Showing time : TimeOfDay seatid 1 ReservationSeat Analysis Model ReservationSeat Design Model Showing showing = showingrepository.

15 Analysis = Design = Implementation Showing time seatid Showing time : TimeOfDay seatid 1 ReservationSeat Analysis Model ReservationSeat Design Model Showing showing = showingrepository.getshowingwithlock(showingid); Reservation reservation = showing.reserveseats(seatids, adultseatcount, teenagerseatcount); reservationrepository.savereservation(reservation); Implementation Model 15 / 문서의제목

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

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

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

19 Model 19 / 문서의제목

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 20 / 문서의제목

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

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 22 / 문서의제목

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

24 Model-Driven Design The MODEL and the heart of the DESIGN shape each other Showing time seatid Showing time : TimeOfDay seatid 1 ReservationSeat DOMAIN MODEL ReservationSeat DESIGN Showing showing = showingrepository.getshowingwithlock(showingid); Reservation reservation = showing.reserveseats(seatids, adultseatcount, teenagerseatcount); reservationrepository.savereservation(reservation); CODE 24 / 문서의제목

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

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

27 UBIQUITOUS LANGUAGE 27 / 문서의제목

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

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

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

31 And Domain-Driven Design Showing Reservation Reservation Seat UBIQUITOUS LANGUAGE Showing time seatid ReservationSeat DOMAIN MODEL Showing showing = showingrepository.getshowingwithlock(showingid); Reservation reservation = showing.reserveseats(seatids, adultseatcount, teenagerseatcount); reservationrepository.savereservation(reservation); CODE 31 / 문서의제목

32 And Domain-Driven Design Showing Reservation Reservation Seat UBIQUITOUS LANGUAGE Showing time seatid ReservationSeat DOMAIN MODEL Showing showing = showingrepository.getshowingwithlock(showingid); Reservation reservation = showing.reserveseats(seatids, adultseatcount, teenagerseatcount); reservationrepository.savereservation(reservation); CODE 32 / 문서의제목

33 And Domain-Driven Design Performance Reservation Reservation Seat UBIQUITOUS LANGUAGE Showing time seatid ReservationSeat DOMAIN MODEL Showing showing = showingrepository.getshowingwithlock(showingid); Reservation reservation = showing.reserveseats(seatids, adultseatcount, teenagerseatcount); reservationrepository.savereservation(reservation); CODE 33 / 문서의제목

34 And Domain-Driven Design Performance Reservation Reservation Seat UBIQUITOUS LANGUAGE Performance time seatid ReservationSeat DOMAIN MODEL Showing showing = showingrepository.getshowingwithlock(showingid); Reservation reservation = showing.reserveseats(seatids, adultseatcount, teenagerseatcount); reservationrepository.savereservation(reservation); CODE 34 / 문서의제목

35 And Domain-Driven Design Performance Reservation Reservation Seat UBIQUITOUS LANGUAGE Performance time seatid ReservationSeat DOMAIN MODEL Performance performance = performancerepository.getperformancewithlock( performanceid); Reservation reservation = showing.reserveseats(seatids, adultseatcount, teenagerseatcount); reservationrepository.savereservation(reservation); CODE 35 / 문서의제목

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

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

38 Conversation Based on Technology Cargo cargoid originid destination customers clearance(opt) weight Haz Mat Code origin destination customers clearance (opt) Routing Service populate cargo_bookings table Database table : cargo_bookings Cargo_id Transport Load Unload "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." 38 / 문서의제목

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

40 3. Patterns of Domain-Driven Design

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

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 41 / 문서의제목

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

43 A King, DOMAN MODEL is RICH, Not ANEMIC <<interface>> ScheduleService reserve(showingid, seats,adultseatcount, teenagerseatcount) : Reservation <<interface>> ShowingRepository -showingrepository ScheduleServiceImpl -reservationrepository <<interface>> ReservationRepository getshowingwithlock(showingid) :Showing savereservation(reservation) ShowingFactory Showing create(dayofyear, showingspecification) : Showing time:timeofyear 1 seatid <<interface>> SeatState 1 1 ReservationSeat 0..1 leftseat 0..1 rightseat 0..* 0..1 Reservation amount:money AbstractSeatState 0..1 nextseatstate 0..1 previousseatstate Occupied Reserved Sold 43 / 문서의제목

44 A King, DOMAN MODEL is RICH, Not ANEMIC SERVICE <<interface>> ScheduleService reserve(showingid, seats,adultseatcount, teenagerseatcount) : Reservation REPOSITORY <<interface>> ShowingRepository -showingrepository ScheduleServiceImpl -reservationrepository <<interface>> ReservationRepository getshowingwithlock(showingid) :Showing FACTORY savereservation(reservation) ENTITY Showing ShowingFactory create(dayofyear, showingspecification) : Showing AGGREGATE time:timeofyear seatid 1 <<interface>> SeatState AbstractSeatState 1 1 ReservationSeat 0..1 leftseat 0..1 rightseat 0..* 0..1 Reservation amount:money VALUE OBJECT 0..1 nextseatstate 0..1 previousseatstate Occupied Reserved Sold 44 / 문서의제목

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

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

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

48 BOUNDED CONTEXT 48 / 문서의제목

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

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

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

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

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

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

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

56 4. Conclusion

57 No Silver Bullet 57 / 문서의제목

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

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

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 60 / 문서의제목

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

62 Resources - Domain-Driven Design, Eric Evans, Addison-Wesley, Patterns of Enterprise Application Architecture, Martin Fowler, Addison-Wesley, Applying Domain-Driven Design and Patterns, Jimmy Nilson, Addison-Wesley, Domain Driven Design Quickly, - Domain-Driven Design Step-By-Step, filesystemfile.ashx/ key/communityserver.components.sitefiles/domain-driven- Design-_2D00_-Step-by-Step.pdf - Domain-Driven Design Community, - Eternity s Chit-Chat, 62 / 문서의제목

63 Thank you.

64 Question.

Lecture 23: Domain-Driven Design (Part 1)

1 Lecture 23: Domain-Driven Design (Part 1) Kenneth M. Anderson Object-Oriented Analysis and Design CSCI 6448 - Spring Semester, 2005 2 Goals for this lecture Introduce the main concepts of Domain-Driven