How Bounded Contexts

Shape Frontend Architecture

Tomasz Ducin  •  ducin.dev  •  Bottega IT Minds

How Bounded Contexts

Shape Frontend Architecture

Tomasz Ducin  •  ducin.dev  •  Bottega IT Minds

Software Architecture

Architecture has goals

Architecture evolves

Architecture is a resultant force

Key Frontend Architecture concern:

Modularity

Hi, I'm Tomasz

tomasz (at) ducin.dev

🦋 @ducin.dev

𝕏  @tomasz_ducin

Independent Consultant & Software Architect, Trainer, Speaker

Software Generalist (FE, BE, DBs, ...)

Bottega IT Minds, Microsoft MVP

ArchitekturaNaFroncie.pl (ANF), Developer Jutra.pl (DJ)

Warsaw, PL

disclaimer #1

Do you expect super duper frontend tactical patterns?

disclaimer #2

Why speaking about DDD & Front-End intersection at all?

disclaimer #1

Why speaking about DDD & Front-End intersection at all?

disclaimer #3

All my claims are based on commercial consultancy
(mid-to-large companies in financial, accounting, energy, publishing and commerce sectors)

🤔

• what problem are we trying to solve?
• how do we know a problem is a problem?
• what causes the problem?
• what are the alternatives?
• what problems do we introduce (accidentally)?

what is more important 🤔

QUESTIONS or ANSWERS?

QUESTIONS

Semantic Boundaries

Bounded Context

Bounded Context

- a boundary within which a (specific and consistent) domain model and a (common, unambiguous) language applies

- linguistic boundary

client state:

• ID
• quantity
• price
• tax
• country-specific tax regulations
• [...]

client state:

• ID
• customer
• quantity
• shipment limitations
• [...]

client state:

• ID
• name
• descriptions, tags, images
• categories
• price
• ratings
• [...]

Heuristics

for distilling bounded contexts

Business Process:
Separate Steps

Alternative Inputs

Alternative Outputs

Information used together

Information which change together

Anti-Requirements

and many, many more...

don't allow semantics

to leak

Anti-Corruption Layer 🧱

FE, BE - separate

Bounded Contexts?

🤨

Client State (Coupling)

Canonical Data Model

Canonical Data Model

- standardized representation of data that serves as a common ground for different systems and applications to exchange and understand data.

Decoupling? 👉|👈 

😒 we don't approve

🤬 it's NOT in the docs

Deployment Architecture

2 questions:

"Every piece of knowledge must have a single, unambiguous, authoritative representation within a system"

- "The Pragmatic Programmer", A. Hunt, D Thomas

Monorepos

monorepos

apps/

  app-A/...

  app-B/...

libs/

  lib-X/...

  lib-Y/...

  lib-Z/...

monorepos

apps/

  app-A/...

  app-B/...

libs/

  lib-X/...

  lib-Y/...

  lib-Z/...

monorepos

apps/

  app-A/...

  app-B/...

libs/

  lib-X/...

  lib-Y/...

  lib-Z/...

😁

(false?) promises:

• faster builds
• easier to bump all packages
• more "order" / clean / elegant / you name it

module boundaries

apps/

  app-A/...

  app-B/...

libs/

  lib-X/...

  lib-Y/...

  lib-Z/...

❌

❌

❌

❌

❌

monorepos

libs/

  flights/

  tickets/

  profiles/

  shared/

  ...

apps/

  application :)

db

tickets

"DDD in Angular"

(Different) Actors 🎭

OMG... that means we gotta talk to people... a lot

🫨

I studied Computer Science
to avoid talking to people

😓

Business Goals 📈

Modularity & LLMs

The Art of Destroying Software

Greg Young, https://www.youtube.com/watch?v=Ed94CfxgsCA

Heuristics are tools