inside out“ „Woha, how could that bug pop up after we changed something at a different place?“ „We can only do integration tests, unit tests are hard to write and are not present“ „Every year the price per feature raises and so do the number of bugs in production“
Conformist Anticorruption Layer Separate Ways Open / Host Service Published Language Aggregates Entities Value Objects Factories Services Repositories D D D
bunch of Bounded Contexts Each Bounded Context contains models and maybe other contexts The Bounded Context is also a boundary for the meaning of a given model
want to achieve by decomposing your monolith? Type What type of monolith are you dealing with? Interactions If you have modules, how are they related to each other in terms of loose coupling? Modules Which vertical / business driven modules are roughly present?
your monoliths. Use the currently present vertical slices as a starting point and match the patterns on them 4 Start with one of the 2-3 migration steps by either pulling out a microservice or by refactoring towards a better internal structure 3 Match the findings of the previous steps with your migration goals and chose 2-3 initial migration steps 2 Identify hot spots and possible quick wins based on the context maps
starter will hardly work here. So you should come up with a short list of „business module wise“ pain points 4 Start pulling out bounded contexts with aggregates towards microservices 3 After having introduced aggregates you may introduce bounded contexts as a next step. Still in the monolith 2 Refactor to aggregates, step by step. Move away from the procedural service driven anemic domain model. Don’t think about microservices at this stage.
an overview of the system By introducing a Context Map we describe the contact between models / contexts The Context Map is also a great starting point for future transformations
Supplier Conformist Anticorruption Layer Separate Ways Open / Host Service Published Language Eric Evans defined those seven context mapping patterns and did not organize them any further. Also Vaughn Vernon stuck to this way of describing them. However we will classify them in: • Upstream Patterns • Downstream Patterns • In-Between Patterns In addition to that we will introduce an eighth pattern.
System Downstream System Upstream Patterns: • Open Host Service Downstream Patterns: • Customer / Supplier • Conformist • Anticorruption Layer In-Between Patterns: • Shared Kernel • Published Language • Separate Ways
System Downstream System Upstream Patterns: • Open Host Service Downstream Patterns: • Customer / Supplier • Conformist • Anticorruption Layer In-Between Patterns: • Shared Kernel • Published Language • Separate Ways
offers a defined set of services that expose functionality for other systems. Any downstream system can then implement their own integration. This is especially useful for integration requirements with many other systems. SOAP / REST for example
publishes Domain Events. This can be done by messaging or feeds. Other Bounded Contexts may subscribe to those events in order react upon them. This is a new pattern, which is not part of the DDD books by Eric Evans or Vaughn Vernon publishes
System Downstream System Upstream Patterns: • Open Host Service Downstream Patterns: • Customer / Supplier • Conformist • Anticorruption Layer In-Between Patterns: • Shared Kernel • Published Language • Separate Ways
customer / supplier relation ship between two teams. The downstream team is considered to be the customer, sometimes with veto rights. Downstream Team discusses model with Upstream Team
the model of the upstream team. There is no translation of models and no vetoing. If the upstream model is a mess, it propagates to the downstream model. The Downstream Team adapts to the model of the Upstream Team
System Downstream System Upstream Patterns: • Open Host Service Downstream Patterns: • Customer / Supplier • Conformist • Anticorruption Layer In-Between Patterns: • Shared Kernel • Published Language • Separate Ways
similar to Open Host Service. However it goes as far as to model a Domain as a common language between bounded contexts. A typical example is the ISBN in the book publishing domain Implements according to Published Language Implements according to Published Language
of a system. This allows teams to find their own solutions in their domain. However there may be a „hidden“ connection between the teams. Look out of for „organizational“ Solutions (Excel, Access, ..)
System Downstream System Upstream Patterns: • Open Host Service Downstream Patterns: • Customer / Supplier • Conformist • Anticorruption Layer In-Between Patterns: • Shared Kernel • Published Language • Separate Ways
Integration Shared Kernel Customer / Supplier Conformist Anticorruption Layer Separate Ways Open / Host Service Published Language Team Communication Event Publisher
to identify governance issues between applications and teams. Transformation A Context Map is an excellent starting point for future transformations: it gives an in-depth insight into integration aspects and subdomain / context relations Bad Models By introducing a Context Map we get a clear view on where and how bad models propagate through application landscapes Politics By not just looking at technical integration aspects the Context Map also helps us in seeing how teams communicate and „play politics“.
their values Value Objects do not have their own lifecycle, they inherit it from Entities that are referencing them You should always consider value objects for your domain model Color Monetary Amount Customer
Object If an object can be considered an Entity or a Value Object always depends on the (Bounded Context) it resides in. Customer Example: A customer is an entity in a CRM-like microservice but not in a microservice that prints badges, there we are just interested in name, job description and Twitter handle
Loan <Entity> Customer <Entity> LoanApplicationForm <Root Entity> <Entity> Aggregates group Entities. The Root Entity is the lead in terms of access to the object graph and lifecycle.
usually only contain an Entity and some Value Objects. Consistency Boundaries Take a look which parts of your model must be updated in an atomically consistent manner One TX per Aggregate Aggregates should be updated in separate transations which leads to eventual consistency Reference by Identity Do not implement direct references to other Root Entities. Prefer referencing to Identity Value Objects
about good a good old OO practice: information hiding Personal opionion: In the advent of POJOs we have unlearned information hiding A blind „Genereate Getters and Setters“ in your IDE is your enemy Battery Cells Status Charger Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell General Information
we need an external access to the cells? Stuff we want to do from the outside: - Start charging - Get current charge level - Get information about the charging Battery Cells Status Charger Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell General Information
mploed
mururu
mamy1326
hiroga
antonarhipov
atsushikoga
nrslib
januswel
kasumi8pon
peacock0803sz
sat0b
cocoeyes02
haruguchi
marktimemedia
thoeni
caitiem20
cassininazir
chriscoyier
jrom
erikaheidi
tanoku
colly
notwaldorf
akmur
hannesfritz
