Language In Context

ddd learning
Notes from Eric Evans' 2019 Explore DDD Keynote
Language In Context

  1. DDD is focusing on the domain, exploring models, and using a ubiquitous language inside a bounded context

  2. Bounded Contexts are where more than one model applies in a particular context. Translation will be difficult unless a ubiquitous language is used. To reduce wated energy and to keep development sane, define the context, set boundaries, apply CI, and standardize the dev process within the context.

  3. The Ubiquitous Language seeks to eliminate translation and needless knowledge transfer

Everyone, devs and domain experts, should seek to apply the UL in all modes of communication. The model is closely tied to the UL. A change to it is a change to the UL.

If terms change, refactor code, charts, documents, and diagrams. Domains experts ensure that terms are correct. Devs ensure that terms are consistent and clear to allow for clear design.

Language in Context

  • In contexts, you can have ambiguity between terms (multiple definitions)
    • Maintain a single definition per term
      • Text on a slide, code/database, microservice, bounded contexts

Bounded Contexts

  • Needs to be easy for devs to see if something is within a bounded context
  • Architecture should be consistent

Canonical definition
* A place to explore a domain model
* Defining language
* Distilling some aspect of the core domain
* Contain multiple models isolated from one another
* The tool, bounded context, isn't intended to make everything tidy

8:31

Bounded Context <> Subdomain <> Organization

  • Part of the problem of understanding is the typical alignment of the three when they aren't in theory. Unfortunately, that exposes the distinction.

    • Cash accounts and credit cards are two examples. They're both, Bounded contexts, subdomains, and departments of an org

  • Biz accounts and personal accts -> org

    • Way people have thought about the software has changed with the org
    • Software has not changed
      • Bounded contexts are designators within that software -> they haven't chaged
    • Reorgs don't magically restructure software systems

  • Shared bounded contexts

    • 3-legged race metaphore: fast/slow + coordinated,
    • Stewardship isn't clear
    • where the diff between bounded contexts, subdomains, and orgs
    • can lead to a big ball of mud
      • incomprehensible interdependencies
      • inconsistent definitions
      • Impossible to understand
    • Inside of a mess you can gain benefits from tidier contexts with models within them
      • models is our attempt to create order
      • A bubble context
        • Isolate a fresh model
        • Evolve to autonomous bubble

Bubble Context

Context Boundaries

* Places to work on dirt with shoes and places to work barefoot

  • Legacy isn't something to get away from
    • Honor the legacy of the system
    • Abundance in maturity (chaotic maturity)

Mature Bounded ConteXts

  • Flush new garden vs a mature one
  • Don't break the working system

Quaint Context

  • The fundamental character of a system doesn't really change even if it isnew and malleable
  • Haven't seen that in awhile

Patch on Patch Context

  • Mitigate risk by avoiding major change
  • change is risky and expensive
  • We gotta get this feature out to tomorrow!

Refactorings

  • Move core domain by creating a bubble context beside it (interchange context)

Generic Subdomain Context

  • Other contexts conform or you isolate with anti-corruption layers

Generic OTS (off the shelf) context

  • We relinquish control and conform to it

Downstream conformist relationsihps

* One context conforms to another
* which concets are conforming
* not just a relational description, part of the design process

Generlist vs specialist

  • Fruad detection (specialist), shopping cart (generalist)

  • specialist contexts should be narrow

    • don't pollute

  • General ones should be broader

  • Lump and split

  • Rigor vs flexibility

    • Some are ridged, some are flexible

House of cards context

  • Many things we associate with teams should be associated with the bounded contexts we work in
    • High test coverage, architecture styles, event sourcing

Microservices

  • Risk/opportunity/bandwagon

  • is a bounded context

    • an oversimplification

  • If you have two different policies in a system, each would need to live in its own bounded context which would live under a parent bounded context

  • Microservices represent risks and opportunities

  • Four kinds of contexts in a microservice

    • Inside a service
    • API of a service -> sometimes a bounded context, sometimes part of
    • clusters of services
      • where there's careful orchetstration between the services, that are bounded contexts
    • interaction between services
    • There's always a level of coordination
    • interchange context