I wanted you to be able to refer back to this. It's not a normal presentation. Please don't take notes, this is publicly available. Think of it as a blog post in presentation format.
** product-delivery team: combination of product, domain experts, developers, testers, etc working together on a customer facing work
Avoiding structural and semantic allocation of responsibilities helps avoid "god" classes and reduces rate of change and duration for rework
Design level allows us to design by focusing on dynamic view, avoiding this
➭ The "linear" phase ➭ The "boundary-setting" phase
For what fits in an orange sticky, think about unit tests. We want to discover units of behaviour. An orange sticky should be the decision of one method of domain logic (and maybe some helpers) Don't get stuck on validations, but don't ignore them either. If you discover you're discussing invariants, represent these with a transactional boundary Make a point to discover policies between events and commands Don't be too strict about grammar. Use it as a heuristic, not a law
Hide stuff you don't want to discuss (a library, another service that you don't want to touch) behind a system sticky. Do this when you're discussing a new feature and you don't want to make big changes When you want to confirm your boundaries, do NOT hide behaviour you own behind a systems sticky. Do this from time to time. Name your policies by the rule they apply ("Always do X when Y", "We don't accept Z combination because of ABC reasons" etc)
If you find you need something special because it's important to you, don't be afraid to add it (like a PM sticky). Do make a consious effort to avoid this however, and only add these if it helps unblock discussions Long names are fine. Now it's good to be descriptive Add hotpots for problems you're discovering, but try to resolve them before finishing the linear phase if possible It's fine to branch. Use vertical space liberally
➭ It answers yes to the following questions:
Does one event correspond to one XUnit unit test or feature? Is the data in aggregate stickies really the minimum amount of data required to guarantee the decision can be made? (ignoring data in command) Is the data in aggregate really the minimum amount of data where we need to enforce immediate consistency? Policies apply one "rule"
Domain services can live in a boundary of their own or within an aggregate Stateless policies are great! Prefer using stale data when possible. This allows you to move your domain service anywhere, so as to reduce coupling. Very useful to remove coupling between the source of the data and the logic that needs that data as input. Experiment!
Small aggregates Good balance of aggregate size and dependencies between aggregates Small number of dependencies between boundaries