DDD and Microservices: At Last, Some Boundaries! (original) (raw)
InfoQ Homepage Presentations DDD and Microservices: At Last, Some Boundaries!
Summary
Eric Evans introduces a few strategic design concepts and explains how they apply to development of microservices, as a tool for teams trying to grow large systems more coherently.
Bio
Eric Evans is the author of "Domain-Driven Design: Tackling Complexity in Software." Eric now leads Domain Language, a consulting group which coaches and trains teams applying domain-driven design, helping them to make their development work more productive and more valuable to their business.
About the conference
Software is Changing the World. QCon empowers software development by facilitating the spread of knowledge and innovation in the developer community. A practitioner-driven conference, QCon is designed for technical team leads, architects, engineering directors, and project managers who influence innovation in their teams.
Key Takeaways
- Micro-services provide a hard boundary between systems
- Ensure a de-facto message format is designed rather than evolved
- Use circuit breakers or anti-corruption layers to guard or translate messages
- Context maps should be realistic, not idealistic, and represent the system as is
- Logical boundaries in monolithic services do not provide hard boundaries
Show notes
What is the connection between domain driven design and micro-services?
- 0:50 Micro-services allow scaling and large numbers of transactions
- 1:10 Domain driven design solves the problem of maintaining large complex problems
- 02:00 One of the most common problems is a failure to create boundaries between systems
- 02:15 Micro-services provide a hard boundary
- 02:35 Just because something is popular doesn't mean it's bad
Why do I like micro-services?
- 03:20 Autonomous teams with isolated implementation
- 03:35 Don't allow micro-services to share databases
- 04:00 Micro-services acknowledge the rough and tumble of enterprises
- 04:45 Treat your services as cattle, not pets
- 05:00 Micro-services are a different way of thinking about design, but the term micro-services has different interpretations
Services and Messages
- 05:40 Services send and consume messages
- 06:00 How do they understand messages?
- 06:20 Messages must be in some bounded context
- 06:40 The context must be bounded in order to understand messages
- 07:40 Sometimes software systems get in a mess and you can't make sense of boundary
Context Maps
- 08:00 Domain Driven Design introduces a context map
- 08:15 Provides an overview of how the services communicate with each other as partners
- 09:15 Requires a common translation between two services, but may imply teams are not autonomous
- 09:40 Introducing a new service where there is a dependency, context map points towards where the power lies; the downstream service conforms to the upstream service
- 11:20 It is possible to write a translator called an 'anti-corruption' layer that provides translations between services
- 11:50 It is possible for the conform relationship to go the other way; the arrow points to the service power
- 12:20 For example, with tax returns, the individual is responsible for the data flow into the service but the service owner (tax authority) is the one that dictates how and when such messages must be sent
Multiple models
- 14:40 There are multiple models; legacy systems, new systems, external systems
- 15:10 Multiple teams will create multiple models
- 15:30 Models need to be clear, not big
- 16:00 Useful models ned crisp definitions and have a clear context
Assertions
- 16:20 Models need to make simple assertions; for example, there are no customers who have never ordered anything
- 16:40 The assertion will be model specific; the prior assertion isn't a universal truth over all models, but may apply to this one
- 16:55 Assertions require boundaries
Containment and mitigation
- 19:00 If you have a service which produces bad messages, it can taint services downstream
- 19:10 The conforming service can prevent the taint from spreading
- 20:00 At this point the context map is fiction, and describes an ideal system rather than what actually exists
- 20:10 Add warning markers to mark where containment may be required
- 20:50 Not all of a large system will be well designed
- 21:30 It would be good to fix the problematic service if it is under the team's control, but this is not always possible
- 21:40 Another way of mitigating is to write an anti-corruption layer; but this changes the power direction pointing to the flaky service
- 22:40 Don't let idealism get in the way of representing a real system
Micro-services as context boundary
- 22:50 Allow high concept modelling in a messy world
- 22:55 Allow specialised models for distinct problems
- 23:45 Having breakers prevents design mistakes from spreading through the system
Interchange context
- 24:50 The internal logic for one service may turn into a de-facto interchange between unrelated services
- 25:30 In natural languages this happens all the time; a German person talking to a Chinese person may likely use English as the interchange language
- 25:55 The problem will have an effect on the original service; the format is unlikely to be optimal for other services
- 28:00 The propagation of the de-facto message format results in it being difficult co change by the original service in the future
- 28:45 Instead of having an implicit interchange context, make it an explicit interchange context with a designed language
- 28:50 The interchange provides a layer of insulation between the original service and the other interchange forms
- 28:55 The original service will need an anti-corruption layer performing translation between the service and the new interchange context
- 29:00 An interchange context is a relatively generic data model for sharing
- 29:20 It is also a place to model protocols of interaction
- 29:50 Allows the language to be tuned to the purpose
- 30:00 Expressing interchange context in terms of service interfaces and messages
- 30:10 Distinct from objects/functions/internals of the service
- 30:40 Prevents distortion/freezing of early dominant contexts
- 31:05 Gives big picture understanding when we have many services
- 31:30 Usually more than one - avoid the enterprise model
Why not use logical boundaries?
- 32:00 Micro-services gives a concrete boundary
- 32:30 The logical partitioning of the system is important but perhaps not the intent of a micro-service
- 33:30 The problem is logical partitioning doesn't work in practice
- 34:00 Logical boundaries in a monolithic system aren't easy to see; with micro-services it's much easier to see
- 35:00 Some techniques are to subtle to survive the real world
Wrap up
- 35:30 Subtle design (such as DDD) requires concrete boundaries
- 36:00 Micro-services have concrete boundaries
- 36:40 Proliferation of services recreate some old problems
- 36:55 Hundreds of services can lead to spaghetti interactions
- 37:15 Context maps help visualise and communicate against the problems
- 37:30 Modest use of interchange context can help produce coherent sets of micro-services
See more presentations with show notes
Recorded at:
Apr 16, 2016