Heuristics

Heuristics

Here are some of the heuristics we follow:

Architectural Patterns Heuristics

• Beware of making one big authoritative model
• Draw Bounded Contexts for your System
• Consider using the Clean Architecture paradigm aka ports and adapters architecture
• Loose coupling is more important than DRY
• Isolate business rules in a domain model away from technical code

Code Organisation Heuristics

• Code packages like nuget packages should be cohesive and well tested
• Interface Segregation Principle also apply on Code Package level
• Arrange code according to domain concepts rather than technical concept

Code Design Heuristics

• Beware of the Primitives Obsession code smell
• Consider Injecting dependenices into constructor
• Consider inititalizing class to a valid state in a constructor
• Consider making Properties readonly for imutability and encapsulation
• Code against abstractions
• Prefer composition over inheritance

Naming Heuristics

• Don’t call your class ‘SomethingHelper’
• Use intention revealing names
• Try to be explicit
• Use Past Tence verb for events
• Prefer nouns for classes
• Prefer verbs for methods

Testing Heuristics

• A Majority of your tests should be fast
• Seperate slow tests from fast tests
• If your code is difficult to test there is probably room for design improvements
• Tests should be repeatable and order shouldn’t matter
• Tests should be able to run in isolation and be deterministic

Validation Heuristics

• There are different types of validation
• input validation
• Business Rule Validation
• Defencive validation and Error Handling
• Isolate business rules in a domain model away from technical code