-
Notifications
You must be signed in to change notification settings - Fork 0
Labels
documentationImprovements or additions to documentationImprovements or additions to documentation
Description
TODO
PROCESS
- TODO: Agile approach
- TODO: Trunk based development as branching strategy
- TODO: Follow Definition of Ready (DoR) and Definition of Done (DoD)
- TODO: Do the Code Review earnestly
- TODO: Keep changelog along with code
- TODO: Manage technical debt
Analysis
- TODO: Use event modeling and event storming
ARCHITECTURE
- TODO: Document architecture (C4 model as example)
- TODO: Separate infrastructure from business logic using hexagonal architecture - ports and adapters pattern
- TODO: Develop Web API using REST principles
- TODO: Use CQRS as driving adapter for the REST API
- TODO: Use Materialized View pattern as a Query source
- TODO: Test architecture with convention tests
- TODO: Use microservices architecture
- TODO: Store secrets safely
- TODO: Introduce configuration server
- TODO: Use feature flags
- TODO: Document architecture details by generating sequence diagrams from code
General Practices
- TODO: Choose strategic patterns and practices with caution
- TODO: Understand the business
- TODO: Keep quality in mind
TOOLBOX
Deployment
- TODO: Infrastructure as Code
- TODO: Use semantic versioning
- TODO: Follow continuous delivery practices
- TODO: Use Terraform to deploy the infrastructure
- TODO: ApplicationInsights for logging and tracing
- TODO: Release toggles to separate deployment from release
Development
- TODO: Follow Design by Contract (DbC) programming techniques (Defensive programming)
- TODO: Utilize .net nullable types
- TODO: Follow clean code practices
- TODO: Develop to be able to use [Find usages] from your IDE
- TODO: Do not add // into the code
COMMITS
- TODO: Use Commit Driven Development Practices
- TODO: Snapshot requirements (docs) as first commit within Pull Request
Packages
- TODO: Use .net centrally managed Nuget packages
- TODO: Extract shared libraries
Domains
- TODO: Use Domain Driven Design patterns and practices
- TODO: Use Event Sourcing pattern
- TODO: Use Optimistic Concurrency
- TODO: Follow exception handling best practices
- TODO: Use Value Objects everywhere in the Domain
- TODO: Behavioural Testing of the domain
TESTING
- TODO: Use TDD approach
- TODO: Use Test Doubles properly
- TODO: Use xUnit as a main code testing mechanism
- TODO: Use Verify as approval testing technique
- TODO: Awareness Testing
- TODO: Test every public development API
- TODO: Prove performance tweaks by benchmarking them
- TODO: Use Azure CI pipeline to build and run tests after each push
Database
- TODO: Use Entity Framework Core to access database
- TODO: Use EFC Migrations
- TODO: Use CaseInsensitive as an explicit SQL DB Collation
- TODO: Test database schema changes
WEB API
- TODO: Develop Web API according to REST rules
- TODO: Keep thin Web Api Controller layer
- TODO: Test your Web API
- TODO: Test Open API schema of your Web API
- TODO: Use common JSON serialization library across the platform
- TODO: Use versioned Web API
- TODO: Use Problem JSON as a standard REST API error response format
- TODO: Use OData as an approach to query Materialized Views
- TODO: Use API Gateway
Documentation
- TODO: Keep user documentation along with the code
- TODO: Use Pandoc to generate documentation from markdown
Security
- TODO: Scan the code base agains voulnerabilities
Sub-issues
Metadata
Metadata
Assignees
Labels
documentationImprovements or additions to documentationImprovements or additions to documentation