Show Menu
Cheatography

Dos and Don'ts Cheat Sheet by

Dos and Don'ts in a Domain-driven Design (DDD) environment also testing suggestions.

How to read

DO
DONT

GLOBAL

One function does one thing
Write module unit tests
Nested if/else
Write component (s)css

FACADE

One facade per feature
Extract logic from facade
Subscribe

STATE MANAGEMENT

ACTION
Use enum for action name
REDUCER
Copy and write into state
 
Write mapping or filter logic
EFFECT
Delegate actions
 
Use mergeMap to to delegate one action into multiple
 
Map server results
 
contra­ctL­ate­stFrom store
SELECTOR
Read store value
 
USE CASE specific mapping, filtering, sorting
 
Chain selectors
 
Mapping logic
 

APPS

Register Modules
Setup Theming (Colors and Typograhy)
Add business logic

DOMAIN / Infras­tru­cture

Get data from domain external sources
Access store
Subscribe

FEATURE

Subscribe in template
Facade in template
Keep component as small as possible
Use angular life cycle onlnit for initia­liz­ation
Use Constr­uctor only for dependency injection
Write components style
Add buisness logic

DOMAIN / Shell

Register feature modules
Add business logic

UTILS

Try to avoid
Write pure functions which are used in feature AND domain

UI

Write dum components whitch can be shared between features
 

TESTING / UNIT TEST

Mock everything
Make use of mockbu­ilder
Test streams with testSc­heduler (marbles)
One expect per it
Use TestBed
Subscribe to observable
If it does commun­icate, it is not a unit test.

TESTING / INTEGR­ATION

Mock server calls
Use correct selector
Test acceptance criteria
Test text, color
Test erver calls
AVOID mulitple cy.visit

TESTING / E2E

Test server calls
Mock
 

Comments

No comments yet. Add yours below!

Add a Comment

Your Comment

Please enter your name.

    Please enter your email address

      Please enter your Comment.