sd - 02 - decomposition

What is requirements analysis

requirement analyses = vertalen van business requirements naar system requirements

onderscheid tussen:

• functional requirements:

  • wat het systeem doet

  • Applicatie specifiek

  • user stories & use cases

    • financial trading / delivery platform / …

• non-functional requirements:

  • wat het systeem moet zijn

  • kwaliteitsattributen: scalibility / reliability / security : maintainability

    • dit is via architectuur gerealiseerd

What is “abstraction-driven design”?

• Abstractions for big stuff, that are familiar

• Tips for abstraction-driven design

Abstraction-driven design = “Fighting complexity with abstraction”

Complexiteit wordt confined in duidelijk gedefinieerde abstractions (boxes)

• Functionaliteit wordt verdeeld over die abstractions

• Kennis encapsuleren

  • Anderen die kennis laten hergebruiken zonder ze zelf te moeten kennen

• Focus op:

  • build abstractions where it matters most

    • complex of riskante domains

  • Abstractions that are familiar

    • concepten gebruiken die de devs al kennen (file, connections, session)

• bv: networking lib gebruiken ipv zelf te implementeren

Tips voor abstraction-driven design

• Start met design aspects, niet met individuele designs

• Denk in regels zoals:

  • “all solutions must do X”

  • “solution Y is just X with one change”

  • “any solution that does X has to also do Y”

• reuse: voor iedere abstractie: maak 1 implementatie, plan voor de 2e, hoop voor een 3e

• Onthoud: abstraction is not free

“Strangling fig” or “Event interception” design pattern for legacy applications

• stapgewijs een nieuw systeem bouwen rond de randen van het bestaande systeem

• nieuwe functionaliteit wordt onderschept via events

• oude systeem wordt langzaam vervangen zonder big rewrite: “until the old system is strangled”

waarom

• geen gigantische rewrites

  • minder risico

• incremental delivery

Double Diamond design process and the core design principles

• Convergent vs divergent thinking, 4 phases and their goals

• Core design principles

Double diamond design proces: divergent thinking → convergent thinking

• divergent: exploring broadly

  • exploring

  • generating ideas

• convergent: narrow down ideas

  • synthesize → maak beslissingen en focus

  • exclusionary, critical

4 phases:

Ensuring you’re solving the right problem

• discover: eerste diamond: helpen begrijpen wat het probleem is

  • spending time with people who are affected by the issueus

• define: 2e diamond: insights gathered van discovery phase helpt om challenge te defineren

• hieruit volgt clear problem statement

Ensuring you create the right solution

• develop: 2e diamond: mensen geven verschillende antwoorden tot gedef probleem → codesigning met verschillende mensen

• deliver: verschillende opl testen op kleine schaal

• hieruit volgt effective solution

Core design principles

• Put people first: start met verstaan van de mensen die de service gebruiken, wat ze nodig hebben, strengths …

• Communicate visually en inclusively: help mensen een gedeelde understanding te krijgen

• Collaborate en co-create: werk samen

• iterate, iterate, iterate: spot errors early / vermijd risico / vertrouw op je ideen

What is a business domain and what does it mean to communicate inclusively/use ubiquitous language

• What is the difference between “ubiquitous language” and “no jargon”

Business domain

Definitie

• Het onderwerp/gebied waarin de software wordt gebruikt

• = “area of expertise” / “sphere of knowledge”

• Business-georiënteerd, niet technologie-georiënteerd

• System design start altijd vanuit de domain, niet vanuit technologie

---

Communicate inclusively & ubiquitous language

Inclusief communiceren

• communicatie moet inclusief zijn foor experts zonder technische kennis

• business jargon, geen technische shit

Ubiquitous language

• Gedeelde taal

• Afkomstig uit de business domain

• Consistent gebruikt door:

  • domain experts

  • ontwerpers

  • ontwikkelaars

• Wordt gebruikt in:

  • gesprekken

  • documentatie

  • modellen en diagrammen

Ubiquitous language vs “no jargon”

Ubiquitous language

• business Jargon is toegestaan, geen technisch

• Verwacht en noodzakelijk voor domain experts

“No jargon”

• Slaat op technische IT-jargon

• Uitzondering: als de business domain zelf technisch is

Kort

• Business jargon: ja

• IT-jargon: nee

3-step process for building microservice architecture

1 Identify and understand system operations

• maak high level domain model

  • praat met experts om in en outs van problem domain te snappen

    • ubiquitous language

• defineer requests: requests naar backend logic om data opte halen / updaten (non-technical)

  • 2 types

    • commands: create / update / delete

    • xquery: read: ui info geven

  • gebruik werkwoorden: accept, cancel, search, create …

2 Define services

• monolith/system opdelen in microservices

  • elk eigen verantwoordelijkheden

• kan met meerdere strategien

  • vermijd dogma: bv niet elke entitiy moet service zijn, …

• Goal is om long term consistent grenzen te vinden

3 define service api en collaborations: hoe de services interacten met elkaar

• bepaal entry points, APIs en events tussen sevices

• operations

  • system operations: invoked door external clients

  • extra operaties om collaboration tussen services toe te staan

• events published

  • welke services collaboraten met andere

3.a beslis welke service is entry point voor iedere system operation

3.b welke methoden nodig zijn om collab tussen services te realiseren (api)

Different Strategies for decomposition (defining services)

• decompose by business capabilities

• by subdomains (DDD)

• by technology

• by data properties

Define services by business capabilities: what an organization does, niet hoe het dit doet

bv:

• food-to-go: order taking en fulfillement

• insurance: claims processing

• bank: transering money

→ business capabilities omzetten naar services

als je shit slecht zit:

• verdelen van 1 capability in meerder microservices:

  • leidt tot sterke coupling / veel communicatie / distributed

  • long descriptions van capabilities: moet duidelijk zijn

  • collections crossing boarders but not entirely compassing them: data / obj collecties overlappen, maar horen niet volledig bij 1

Different Strategies for decomposition (defining services)

• decompose by business capabilities

• decompose by subdomains

• by technology

• by data properties

een enkel domain model voor hele organisatie is te complex

→ decomposeer in subdomains

• elk subdomain heeft eigen domain model

• wordt begrepen in afgesloten context

bv:

• voor subdomain x kijken we enkel naar fields 1-3 in user profile

• elk ticket heeft 2 delen: 1 gaat naar de keuken ander gaat op de zak

Different Strategies for decomposition (defining services)

• decompose by business capabilities

• decompose by subdomains (DDD)

• decompose by technology

• by data properties

goed

• verschillende technologien voor ≠ needs: rust voor performance

• independent scaling / db keuzes

slecht

• layered architecture

→ best wanneer overlapt met capability / subdomain, technologie mag niet primaire driver zijn

Different Strategies for decomposition (defining services)

• decompose by business capabilities

• decompose by subdomains (DDD)

• decompose by technology

• decompose by data properties

• privacy

• GDPR

zones:

• green zone met minder sensitief

• red zone met sensitiever

handig in bepaalde sectoren, maar extra complexity

[extra] obstacles voor decomposition

network latency:

• vermijd frequent round trips

sync operations houden availability tegen

• services async tov elkaar laten werken

application data is verspreid over db van verschillende services

god classes prevent decomposision

Most important considerations for creating good diagrams

Most important considerations for creating good diagrams

Belangrijkste aandachtspunten:

1. Consistente symbolen: zelfde boxen en lijnen betekenen altijd hetzelfde.

2. Simplicity: focus op wat je wil communiceren, niet op volledige correctheid.

3. Diagramtype bepaalt betekenis van boxen en lijnen

• domain diagram:

  • elements: domain objects

  • relations: inheritance / associatie / dependencies / …

    

• sequentie diagram: shows one possible sequence of interactions

  • elements: objects

  • relations: interprocess communication

    

• process diagram: gehele workflow van een systeem

  • elements: processes

  • relations: control flow + data flow

  

• service diagram: shows unordered graaf van services en hun interacties

  • elements: services en actors

  • relations: interaction