Brownfield Domain Driven Design

42
Brownfield Domain Driven Design Bring your project to the next level without breaking things (nor people)

Transcript of Brownfield Domain Driven Design

Page 1: Brownfield Domain Driven Design

Brownfield Domain Driven

DesignBring your project to the next level

without breaking things (nor people)

Page 2: Brownfield Domain Driven Design

About me

@nicolopigna- PHP developer- Team leader / Software engineer at Rocket Labs, Berlin

We proudly run Seller Center, the largest Rocket Internet Marketplace solution.

Popular clients: Zalando (Europe), Lazada (south Asia), Linio (south America), Global Fashion Group

Page 3: Brownfield Domain Driven Design

Why “Brownfield”?

More challenging and fun than greenfield!Majority of cases.

Open knowledge harder to find.Examples start from the assumption of a greenfield.

“Greenfield is exciting at first, but taking a brownfield project and giving it new life, well, is just priceless!”

Me on Twitter

Page 4: Brownfield Domain Driven Design

Why Domain Driven Design?

● Non-trivial domain model

● Linguistic boundaries applied to the code

● Design and code reflect the same concepts 1:1

● Iterative knowledge distillation

● Both tactical and strategic tools

Page 5: Brownfield Domain Driven Design

No, let’s notCRUDish applicationsGeneric subdomains

Yes, we can● In your core domain● In heavy business-logic

parts of your application● In strategic supporting

domains

Where should I apply it?

i.e. where you make most of your money.

Can we outsource or buy it? Then it’s one of those.

Page 6: Brownfield Domain Driven Design

Is it difficult? How do we change?

Team

● learn new concepts● mindshift is not immediate● eradicate CRUD design● design business first, then data

structures

Management

● handle the change● manage adaptation time● active part of design process

Organisation

● involve business experts● face potential change● introspect processes

Page 7: Brownfield Domain Driven Design
Page 8: Brownfield Domain Driven Design

Your brownfield

Monolithic

High-coupling

Single-data-store

We-tried-to-build-some-unit-tests-but-it’s-impossible-to-mock-everything-or-refactor-let’s-use-integration-tests-instead.

*all the bad things in this slide are written with Comic Sans and poor contrast on purpose.

HugeChange-here-break-there

Page 9: Brownfield Domain Driven Design

BIG BALL OF “MUD”

Page 10: Brownfield Domain Driven Design

BIG BALL OF “MUD”

Hey, at least it works...Don’t know exactly how, but it does!

Page 11: Brownfield Domain Driven Design

Where to start from?

Ok, we need some Repositores, then a Domain/Model directory which will contain AggregateRoots, Entity, ValueObjects, etc.

Yes! Oh, don’t forget about Domain Services, the Application layer and a new event system which we’ll definitely need.

What about a new structure for controllers and UI? They’re definitely part of our Bounded Context! Let’s reuse our DB connection class, so we also need a Shared Kernel.

Page 12: Brownfield Domain Driven Design
Page 13: Brownfield Domain Driven Design

Instead...

Page 14: Brownfield Domain Driven Design

Context mapping

● Define your core domain, supporting and generic subdomains

● Define the relations between them and with other external systems

● Define behavior at boundaries and grey areas

Page 15: Brownfield Domain Driven Design

Event storming

➔ Describe your business through events, what/who caused them, what is the “subject” of your events.

➔ Invite the “right people”, brainstorm, discuss, reach a first representation of your business model. Just let it happen.

Page 16: Brownfield Domain Driven Design

DON’T JUST SKIP IT!

Ubiquitous Language

The UL is what takes all things (and people) together.- It dramatically lowers communication and cognitive load, providing

a common ground, understandable by anyone.- It defines and explains what domain objects are, how they behave

and the relations between them.

How can you even start coding something that you haven’t defined in terms of concept and behavior!?

Page 17: Brownfield Domain Driven Design

Ok. Finally...

Page 18: Brownfield Domain Driven Design

Yeah! We’re finally writing some code now!

Markers and sticky notes were making me feel so uncomfortable...

The evil facilitator shouted at me when I said “cronjob” :’(

We were always talking about “Product”, but I think I will call this class “Article”. Buhahaha!

product.name is varchar(50) or varchar(255)?

Page 19: Brownfield Domain Driven Design

Where should we start applying DDD from?

Are we confident with DDD, SOLID

and refactoring strategies?

Let’s start with our Core Domain

yes

Did someone at least read the Blue and Red

books?

no

yes

no

Let’s start with a Supporting Subdomain

Read them...

now again...

Page 20: Brownfield Domain Driven Design

Keep your UI away

CONTROLLERS

FORMS

TEMPLATES

YOUR FAVORITEMVC FRAMEWORK

Services(Endpoint / Private)

Model

Repositories

Commands

Events

✗✓

Page 21: Brownfield Domain Driven Design

CQRS? Yes, please!

Your database

Command

“Write” Model● Expresses your business

behavior● Changes the state of the

system● Doesn’t expose internal

state

Query

● Shapes information based on representation type

● Never changes the state of the system

● Exposes internal state

“Read” Model

Page 22: Brownfield Domain Driven Design

Haiku of the code duplication

CQRS is applied,duplication comes in.Everything is quiet.

Page 23: Brownfield Domain Driven Design

Change your state through events

DoSomethingCommand

ServiceUnit Of Work

load($aggregateRootId)

AggregateRoot

doSomething()

AggregateRootAggregateRoot● Something

Done

RepositoryAggregateRootcommit()

flushEvents()

Events persist($events)

EventBus

post($events)

Page 24: Brownfield Domain Driven Design

Event sourcing? Read storage?

IT’S A TRAP!

Page 25: Brownfield Domain Driven Design

Event sourcing? Read storage?

1 - Added architectural complexityEvent applicationEvent replayingSnapshots

Page 26: Brownfield Domain Driven Design

Event sourcing? Read storage?

1 - Added architectural complexityEvent applicationEvent replayingSnapshots 2 - Infrastructure and costs

Dedicated data storage (forget MySQL!)Remote communication (via message

broker, REST interface, etc.)

Page 27: Brownfield Domain Driven Design

Event sourcing? Read storage?

1 - Added architectural complexityEvent applicationEvent replayingSnapshots 2 - Infrastructure and costs

Dedicated data storage (forget MySQL!)Remote communication (via message

broker, REST interface, etc.)

3 - Eventual consistencyThink about consequencesImplement resilient behaviorAdvanced UI techniques

Page 28: Brownfield Domain Driven Design

Oh! Think twice!

Page 29: Brownfield Domain Driven Design

Protect your new code!

STRICT RULE: Code from the Big Ball of Mud must not leak into the new BCs nor vice-versa.

THEN HOW DO THEY INTERACT?

BY MAGIC?

Page 30: Brownfield Domain Driven Design

MEET THE

ANTI-CORRUPTION LAYER

Page 31: Brownfield Domain Driven Design

MEET THE

ANTI-CORRUPTION LAYER

YOU SHALL NOT PASS!!!

Page 32: Brownfield Domain Driven Design

MEET THE

ANTI-CORRUPTION LAYER

YOU SHALL NOT PASS!!! At least, not before I can convert you to something meaningful for your destination context...

Page 33: Brownfield Domain Driven Design

Anti-corruption layer

Legacy context

Database

ACL

Adapters

Converters

Identity Maps

Bounded Context

Page 34: Brownfield Domain Driven Design

Anti-corruption layer

Legacy context

Database

ACL

Adapters

Converters

Identity Maps

I’m here to stay!!!

Bounded Context

Page 35: Brownfield Domain Driven Design

Anti-corruption layer

Legacy context

Database

ACL

Bounded Context

Adapters

Converters

Identity Maps

place interfaces here

I’m here to stay!!!

Page 36: Brownfield Domain Driven Design

Anti-corruption layer

Legacy context

Database

ACL

Adapters

Converters

Identity Maps

I can fly away, now!

Bounded Context

place interfaces here

Page 37: Brownfield Domain Driven Design

What happens next?

My new shiny BC

Our soon-to-be-shrunk BBoM

Anti-corruption layer

Page 38: Brownfield Domain Driven Design

What happens next?

My new shiny BC

Our shrinking BBoM

Anti-corruption layer

My second shiny BC

Page 39: Brownfield Domain Driven Design

What happens next?

My new shiny BC

Our shrinking BBoM

Anti-corruption layer

My second shiny BC

Page 40: Brownfield Domain Driven Design

What happens next?

My new shiny BC

Our shrinking BBoM

Anti-corruption layer

My second shiny BC

But of course it’s easier now!

Page 41: Brownfield Domain Driven Design

From distributed Bounded Contexts to μServices

μS = lim Bc(nuc)nuc→ 1

Page 42: Brownfield Domain Driven Design

Thank youfor listening!

Time for muddy questions!