Frontend Architecture: How to Build a Zoo?

Frontend Architecture: How to Build a Zoo? Thomas gossi Gossmann unistyler gossi gos.si

What is Software Architecture? - Architecture is a skill, not (just) a role - The ability to design a system, reason about tradeoffs and understand the design - Flow of decisions (instead of upfront design work) - “Software architecture is the stuff that’s expensive to change” Examine this while building a zoo Disclaimer: I’m not a domain expert for a zoo. This is all made up.

Part 1 Strategic Design Level 1 Zoo

What does this product do? (1)

What does this product do? (2)

What does this product do? (3)

Identify the Domain ● Why do People come to the Zoo? ○ ○ ○ ○ Animals (Fauna) ? Plants (Flora) ? Info-/Entertainment ? Food & Drinks ?

Identify the Domain Core Supporting Generic Animals Plants Food & Drinks Info-/Entertainment Restrooms

Distilling the Domain https://www.zoo-berlin.de

Distilling the Domain Themed Areas Aviary Savanna Antarctica Asia Mountains Africa Predators Aquarium Oceania

Bounded Contexts ● ● ● ● ● Multiple models can co-exist in a big project Contexts need explicit boundaries Model strictly consistent within the context Clear definitions communicate the purpose Context gives autonomy

Bounded Contexts Option 1: Compounds Reasons: ● ● ● Picture from: https://www.glmv.com/work/zoo-boise-master-plan/ They have natural boundaries Can react to outside events Autonomous inside

Bounded Contexts Option 2: Separate by Functional Staff Reasons: Zookeeper Medical Staff - Anthropometry - Blood samples - Excrements

Food - Water - Clean compound Gardener - Which plants are growing? - What are toxic plants to an animal? ● ● Functional teams Ubiquitous language by discipline

Bounded Contexts Option 3: Areas Reasons: ● ● ● Cross-Functional teams per area Follows the team’s communication structure (Conway’s law) Keeps communication paths short

Bounded Contexts Compounds Reasons: ● ● ● Picture from: https://www.glmv.com/work/zoo-boise-master-plan/ Natural Boundaries are a great metaphor I’m not a domain expert for Zoo at all Use themed areas for hierarchical organization

Zoom Levels Level 1 Zoo Level 2 Area Level 3 Compound Level 4 Code

C4 Model model for visualising software architecture “maps of your code” Simon Brown c4model.com

Vocabulary = Scary Generic Co nte xt M Subdom ap pin ain domain b u S g portin g in Sup ling l i t s Di ext nded Cont Bou or C De -co e mp osi n ai m Do tion nguage us La Ubiquito the a Dom

Zoom Levels You Business Level 1 Level 2 Entire Business Zoo Area Level 3 Compound Level 4 Business Capabilities Business Services Business Rules Code

Zoom Levels Level 1 Level 2 Business C4 You Area Level 3 Compound Level 4 Entire Business Business Capabilities Business Services Business Rules Context Containers Components Code Zoo Code

Zoo Folder Structure Level 1 Zoo

Strategic Design Result ★ ★ ★ ★ Understand the domain Distilled the domain into manageable pieces Carved out bounded context Established a language that works across disciplines

Part 2 Tactical Design Level 2 Area Level 3 Compound

Models Expressed in Software Value Objects Repositories Aggregates Entities Events Services Factories Level 2 Area

Aggregates Aggregate Value Object Backend Value Object Entity Root Entity Frontend

Aggregates Aggregate Value Object Backend Value Object Entity Root Entity Aggregate’ Value Object’ Frontend Value Object’ Entity‘ Root Entity’

Services Backend Frontend Domain Service Business Process (eg. feeding Animals)

Services Backend Frontend Domain Service UI Business Process (eg. feeding Animals) Screens Forms Status Elements

User Interfaces

Component Classification Areas Use for housing multiple compounds (Screens/Routes/Pages) Pathways The same walking infrastructure for visitors of a zoo

Component Classification Compounds A component representing a compound Interior Custom tailored interior for one compound Carryables Elements that can be moved around (from one compound to another)

Models Expressed in Software Value Objects Repositories Aggregates Entities Events Services Factories Level 2 Area

Event Storming Event Command Read Model System Policy Actor Collaborative exploration of complex business domains Alberto Brandolini eventstorming.com

Models Expressed in Software Value Objects Repositories Level 2 Area Aggregates Entities Commands Events Services Factories

OOUX Object Contents Actions Metadata Object Oriented UX Object-Oriented UX offers a better way to break up complexity, allowing us to work iteratively and holistically Sophia Prater ooux.com

An OOUX Animal Animal Watch Name Feed Fur Pet Family Genus Diet

Backend + Frontend Level 2 Area Repositories Backend Value Objects Events Frontend Factories Entities Aggregates Commands Services

Backend + Frontend Level 2 Area Repositories Backend Factories Value Objects Events Aggregates Entities Commands Services Objects Content Frontend Metadata Actions UI

Backend + Frontend (Communication) Repositories Backend Area Factories Value Objects Events Level 2 Aggregates Entities Commands Services Objects Content Frontend Metadata Actions UI

Backend + Frontend (Organization) Repositories Backend Area Factories Value Objects Events Level 2 Aggregates Entities Commands Services Objects Content Frontend Metadata Actions UI

Separate UI and Business Logic Business Logic ● ● ● Visual Representation Aggregates / Entities / Value Objects (Nouns) Actions (Verbs) Policies & Rules Communicate System State Offer Behavior ● ● Benefits ● ● ● ● Maintainability Readability The feeling of “home” Fast feature development

Area Folder Structure Theme Area Bounded Context Business Logic UI Bounded Context

Tactical Design Result ★ ★ ★ Frontend Modeling = Backend + Design Separate UI and Business Logic Component Classification that follows the established language

Part 3 Code Level 4 Code

Aggregate / Reactivity ● Plain JS/TS (Framework Agnostic) ● Connect to your Reactivity System (UI / State Management)

What’s your choice? Aggregate / Reactivity ● ● Plain JS/TS (Framework Agnostic) Connect to your Reactivity System (UI / State Management) Classes ● ● (de)serialization (re)hydration Functional ● ● DTO transforms

CQS: Command & Query Separation Methods to either be commands that perform an action or queries that respond data, but neither both! Queries - Questions: Ask facts about the system Abilities/Authorization: Control access Actions & Commands - Command Design Pattern Commands: Used in Backend to perform business logic Actions: Used in Frontend to connect vocabulary with designers and probably call commands in the backend

Queries Questions: Abilities: Ask facts about the system? Control access Expect to have hundreds of these

Queries Abilities: Control access Picture from: https://www.glmv.com/work/zoo-boise-master-plan/

Queries ❌ DO NOT ✅ DO Inline conditionals (in templates) Extract into function

Actions Cause side-effects / Invoke commands on the backend

Connect to your UI UI Code is reduced to its essentials Connecting UI elements with your existing business logic

Deterministic Behavior and State Management Example: Using a Statechart to control the mood of monkey Deterministic behavior Use existing business logic

Pure Core ● Extract core into plain JS/TS ○ ○ ○ ● ● ● ● Aggregates / Entities / Value Objects Actions Abilities & Questions Framework agnostic Control your app through core High and excellent test coverage Use folders as signposts

Use folders as signposts Three examples for core/ Files + Folder give a home Choose based on your needs

Code Result ★ ★ ★ ★ ★ ★ Core layer in plain JS/TS Unit testing for your business logic Connect them to your reactivity system Connect core to UI, machines and other parts Use CQS design pattern Use folders as signposts

Summary ★ ★ ★ ★ Use available methodologies (EventStorming, OOUX, Atomic Design) Extract and apply the essence Establish your own language bound to your product Let the code speak your product

Thank you Thomas gossi Gossmann unistyler gossi gos.si