Dos and Don'ts in a Domain-driven Design (DDD) environment also testing suggestions.
|
DO
|
|
|
DONT
|
|
|
One function does one thing
|
|
|
Write module unit tests
|
|
|
Nested if/else
|
|
|
Write component (s)css
|
|
|
One facade per feature
|
|
|
Extract logic from facade
|
|
|
Subscribe
|
|
|
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
|
|
|
|
contractLatestFrom store
|
|
|
|
SELECTOR
|
Read store value
|
|
|
USE CASE specific mapping, filtering, sorting
|
|
|
|
Chain selectors
|
|
|
|
Mapping logic
|
|
|
Register Modules
|
|
|
Setup Theming (Colors and Typograhy)
|
|
|
Add business logic
|
|
|
Get data from domain external sources
|
|
|
Access store
|
|
|
Subscribe
|
|
|
Subscribe in template
|
|
|
Facade in template
|
|
|
Keep component as small as possible
|
|
|
Use angular life cycle onlnit for initialization
|
|
|
Use Constructor only for dependency injection
|
|
|
Write components style
|
|
|
Add buisness logic
|
|
|
Register feature modules
|
|
|
Add business logic
|
|
|
Try to avoid
|
|
|
Write pure functions which are used in feature AND domain
|
|
|
Write dum components whitch can be shared between features
|
|
|
Mock everything
|
|
|
Make use of mockbuilder
|
|
|
Test streams with testScheduler (marbles)
|
|
|
One expect per it
|
|
|
Use TestBed
|
|
|
Subscribe to observable
|
|
|
Mock server calls
|
|
|
Use correct selector
|
|
|
Test acceptance criteria
|
|
|
Test text, color
|
|
|
Test erver calls
|
|
|
Test server calls
|
|
|
Mock
|
|
No comments yet.
Cheatography n. The art of mapping complex subjects into clear, instantly navigable reference guides.
