Tweet
Tweet

Slide 1

Slide 1 text

Bounded Context – Problem or Solution? Eberhard Wolff Head of Architecture https://swaglab.rocks/ https://ewolff.com/

Slide 2

Slide 2 text

Why is this Talk? •Bounded Context seems simple …but it’s not. •Goal: Clear up the confusion.

Slide 3

Slide 3 text

Bounded Context Bounds Domain Model i.e. Code Ubiquitous Language

Slide 4

Slide 4 text

Order Process Invoicing Process Bounded Context Example Invoicing VAT Shipping Tracking Delivery Accept order Shopping Cart

Slide 5

Slide 5 text

Order Process Invoicing Process Bounded Context Example Customer e.g. billing address Product e.g. price Shipping Customer e.g. shipping address Product e.g. size Product e.g. marketing information Customer e.g. product preferences

Slide 6

Slide 6 text

Why is Bounded Context so Important? •Core pattern of Domain-driven Design •Limits the context of a ubiquitous language •Central to structuring systems into domain models •Also defines the scope of a team

Slide 7

Slide 7 text

Bounded Context: Three Implications Ubiquitous Language Domain Model Teams

Slide 8

Slide 8 text

Order Process Invoicing Process Bounded Context Example Customer e.g. billing address Product e.g. price Shipping Customer e.g. shipping address Product e.g. size Product e.g. marketing information Customer e.g. product preferences Ubiquitous Language? …or just a domain model? Teams?

Slide 9

Slide 9 text

Bounded Context solves three problems…

Slide 10

Slide 10 text

Bounded Context solves three problems… …and that might be a problem.

Slide 11

Slide 11 text

Is there a simpler way?

Slide 12

Slide 12 text

Bounded Context Ubiquitous Language

Slide 13

Slide 13 text

Ubiquitous Language Definition •One language …in written language …in spoken language …in code

Slide 14

Slide 14 text

Ubiquitous Language & Bounded Context Within each Bounded Context, you will have a coherent dialect of the Ubiquitous Language. Eric Evans Domain-driven Design: Tackling Complexity in the Heart of Software

Slide 15

Slide 15 text

Ubiquitous Language Definition •Project have their own language •You can identify a project by an expression of its language.

Slide 16

Slide 16 text

Ubiquitous Language: More Examples •Code implements unambiguous logic. •Designing these rules is the main challenge. •Prerequisite: Find the Ubiquitous Language that captures the central business ideas. •Often terms in natural language are ambiguous. •Bounded Contexts helps: Terms might be unambiguous in a Bounded Context. •There are many non-trivial examples.

Slide 17

Slide 17 text

Who is a Customer of a Hotel? Invoicing SWAGLab GmbH Bei den Mühren 1 20457 Hamburg Registration Eberhard Wolff Kaiserslautern Single person Payment Eberhard Wolff (Card holder)

Slide 18

Slide 18 text

Invoice at a Major Hotel Chain… This doesn‘t work because there are all these IT systems we need to integrate. Where did you do the booking? Your website This my private address. Can I get an invoice with the correct address as provide in the booking?

Slide 19

Slide 19 text

Who is a Customer of a Hotel? Eberhard Wolff SWAGLab GmbH Bei den Mühren 1 20457 Hamburg

Slide 20

Slide 20 text

Ubiquitous Language: Concrete Advice •Very important concept •Good tool to analyze and understand domains •Great to understand different concepts in a domain •There is not just one ubiquitous language …therefore, there can’t be just one domain model …and business entities are complicated (customer)

Slide 21

Slide 21 text

Bounded Context Domain Model

Slide 22

Slide 22 text

Domain Model Definition •“Domain Model” sound like a conceptual model …or a diagram? •But really it is about a “model expressed in software” i.e. working code that implements business logic •Implemented using e.g. Tactical Design

Slide 23

Slide 23 text

Ubiquitous Language -> Domain Model? Invoicing SWAGLab GmbH Bei den Mühren 1 20457 Hamburg Registration Eberhard Wolff Kaiserslautern Single person Payment Eberhard Wolff (Card holder) A different Ubiquitous Language should be implemented by a different Domain Model Helpful?

Slide 24

Slide 24 text

Public Information Changeable Internals Module Information hiding: Internals can be changed freely because public information remain unchanged.

Slide 25

Slide 25 text

Interfaces Code / systems Microservice

Slide 26

Slide 26 text

Public Methods Instance Variables Class

Slide 27

Slide 27 text

Interfaces Code / systems Team

Slide 28

Slide 28 text

Domain Model vs Modul •Modul is more general (technical or business) •Modules can form a hierarchy. …unlike Bounded Contexts. •Core to really implement complex systems

Slide 29

Slide 29 text

Domain Model vs Ubiquituous Language •Different ubiquitous languages are a very strong hint to separate things in software, too. •Main benefit of Bounded Context for software architecture. •Should there be exceptions?

Slide 30

Slide 30 text

Modules with Shared Domain Models Registration Bounded Context Module Microservice 1 First part of registration Microservice 2 Second part of registration A shared domain model hints a tight coupling. A sound example will have microservices with different bounded contexts.

Slide 31

Slide 31 text

Modules with Shared Domain Models Registration Bounded Context Module Microservice Communication to other services Frontend Logic Separate technical modules inside a Bounded Context are natural. Might use ports & adapters instead.

Slide 32

Slide 32 text

Modules with Shared Domain Models •Sharing a domain model but separating parts of the domain logic leads to tight coupling. •Should be obvious, but it’s not. •Sharing a domain model and separating technical parts makes lots of sense.

Slide 33

Slide 33 text

Public Information = Data Changeable Internals = Data Customer Module? Information hiding doesn’t really work if the public information is just an interface to some data. The General Universal Customer Model might be too complex.

Slide 34

Slide 34 text

Public Information: Interface to create an invoice Changeable Internals: How invoice is generated Functionality: Natural Modules Information hiding works only if the public information is an interface to functionality with hidden implementation.

Slide 35

Slide 35 text

Easier Alternative: Just Modules •Don’t talk about Ubiquitous Language •Ask people to organize a system by functionality. •Results very similar. •Might be the easier approach.

Slide 36

Slide 36 text

Domain Model: Concrete Advice •Focus on: Organize the architecture by functionality not by data! •Core value of Bounded Context for architectures •Don’t get caught up in the details of the Bounded Context definition!

Slide 37

Slide 37 text

Bounded Context Teams

Slide 38

Slide 38 text

Strategic Domain-driven Design •Relations between Bounded Contexts somehow become relations between teams.

Slide 39

Slide 39 text

Example: Customer / Supplier •What if the successful implementation of an important bounded context depends on another bounded context? •Team have customer or supplier role. •Customer influences planning of supplier. •Important bounded context -> customer role •IMHO a clearly a valid approach!

Slide 40

Slide 40 text

No content

Slide 41

Slide 41 text

No content

Slide 42

Slide 42 text

No content

Slide 43

Slide 43 text

https://software-architektur.tv/2021/08/27/folge72.html

Slide 44

Slide 44 text

Too Complicated •Three relations •Nine collaboration patterns •Mix pure organization (e.g. Customer / Supplier) and pure technical approaches (e.g. Published Language) •Hard to fully grasp

Slide 45

Slide 45 text

Inverse Conway

Slide 46

Slide 46 text

Inverse Conway Order Process Delivery Invoicing

Slide 47

Slide 47 text

Inverse Conway Order Process Delivery Invoicing Modul Modul Modul

Slide 48

Slide 48 text

More than Bounded Context •Teams are not just organized by Bounded Context •E.g. infrastructure teams

Slide 49

Slide 49 text

Team = Bounded Context? •Inverse Conway is too simplistic •One team can work on more than one BC •It might be fine for multiple teams to work on one Bounded Context. –Might be needed due to deadlines –Might not impact productivity too much because things are separated i.e. by technology.

Slide 50

Slide 50 text

Beyond Strategic Design •We need a more general model …that should also be simpler.

Slide 51

Slide 51 text

Team Topologies Stream-aligned team Platform team Enabling team Complicated Subsystem team XaaS Collaboration Facilitating XaaS

Slide 52

Slide 52 text

https://software-architektur.tv/2024/04/18/folge213.html

Slide 53

Slide 53 text

Conclusion

Slide 54

Slide 54 text

Bounded Context Talks about … Ubiquituous Language: Useful Domain Model: Consider general module concept instead …and build modules by functionality Teams: Strategic Design is complex and not very powerful Consider Team Topologies instead!

Slide 55

Slide 55 text

https://software-architektur.tv/2024/06/14/episode220.html

Slide 56

Slide 56 text

WIR SUCHEN MITGESTALTER:INNEN swaglab.rocks/karriere

Slide 57

Slide 57 text

TRINK EINEN VIRTUELLEN KAFFEE MIT MIR! https://calendly.com/eberhard-wolff-swaglab/

Slide 58

Slide 58 text

Download here! Send email to [email protected] Slides + Sample Microservices Book DE / EN + Sample Practical Microservices DE/EN + Sample of Continuous Delivery Book DE Powered by Amazon Lambda & Microservices Email address logged for 14 days, wrong addressed emails handled manually