sd - 02 - decomposition

● What is requirements analysis

requirement analyses = vertalen van business requirements naar system requirements

onderscheid tussen:

• functional requirements: wat het systeem doet (user stories / use cases): financial trading / delivery platform / …

• non-functional requirements: kwaliteitsattributen: scalibility / reliability / security : maintainability

  • dit is via architectuur gerealiseerd

[extra: slide 5-20] kennis deling en reproduceerbaarheid

• code designs verbergen complexitet: complexe systemen worden beheersbaar via duidelijk abstractions

• acstraction-driven design

  • kennis in abstracties steken

  • laat anderen die abstracties gebruiken zonder zelf die kennis te hebben

  • kennis deelbaar en reproduceerbaar maken

• abstracties herken baar zijn

• hergebruik in gedachten

● “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”

[extra] design process (dacht da dit die kk diagrams ging zijn ma bon)

• double diamond design proces: divergent thinking → convergent thinking

  • divergent: exploring / generating ideas

  • convergent: narrow down ideas: make decisions en focus

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

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

hieruit volgt clear problem statement

• develop: 2e diamon geeft verschillende antwoorden tot gedef probleem

• deliver: verschillende opl testen op kleine schaal

hieruit volgt effective solution

• 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

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

    

● 3-step process for building microservice architecture

1 Identify and understand system operations

• maak high level domain model

  • gebruik high level taal hiervoor

  • maak inital domain model

• defineer requests: requests naar backend logic om data opte halen / updaten

  • commands: create / update / delete

  • query: read: ui info geven

2 Identify services

• decomposeer monolith in services met duidelijke verantwoordelijkheden

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

• Meerdere boundaries: meerdere stabiele services gebaseerd op wat weinig verandert, niet op technische lagen.

3 define service api en collaborations

• bepaal entry points, APIs en events tussen sevices

• system operations: invoked door external clients

• events published

• collab met andere services

→ beslis welke service is entry point voor iedere system operation

→ 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

en dan 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

• rust voor performance

• independent scaling

• apparte db shit

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