Patterns Reading
Architecture patterns
Design patterns
Reactive
Reactive Extensions aren't really patterns but it does fit the idea of categorizing a collection of design approaches
Reactive Manifesto
StackOverflow: Is it possible to build a Reactive Application using a non-Functional language?
Distributed systems patterns
Web application patterns
- Webapp patterns: Collection of patterns and web-app idioms. Mix of GOF and some very specific-to-browsers idioms.
- SAM (State-Action-Model): a software engineering pattern that helps manage the application state and reason about temporal aspects with precision and clarity. Modern Software Engineering practices are essentially based on Functions (Actions) and Types which encourage a sprawl of unstructured assignments and event handlers. SAM's founding principle is that State Mutations must be first class citizens of the programming model. Once that principle is accepted, proper temporal semantics can be articulated.
Patterns miscellany
- Avoiding the soft delete anti-pattern: The main problem with soft deletion is that you’re systematically misleading the database. ... (foreign key constraints, uniqueness constraints) ... Because you’re misleading the database, you also encounter problems with querying the data. You can no longer rely on SELECTs to only return live data; you have to remember to check the deletion marker in each WHERE clause (and in each JOIN; I nearly forgot about that while writing this, a reflection of the many times I’ve forgotten about it while implementing this).
- Alternative 1: YOLO. Just delete.
- Alternative 2: Lifecycle. For entities that have a lifecycle, one option is to consider end-of-life as part of that lifecycle.
- Alternative 3: Temporal tables. The previous approach involves moving deletion from an irritating persistence detail to a first- class part of the application logic. The mirror image is to instead make it a first-class feature of the database.
- Alternative 4: Delete them all and let the data warehouse sort it out. As I said above, problems with soft deletion apply primarily to databases containing an application’s current state. It’s increasingly common for an application to have multiple databases (one database per microservice, for instance), and multiple other data sources (3rd-party analytics services, for example), raising the need for some further data store (a data lake and/or warehouse) to integrate these multiple data sources. You typically want a data warehouse to surface historical data anyway for reporting purposes, so it makes sense to outsource your historical record keeping to this data infrastructure; in that case, you can delete from the application’s own data store with impunity.
Detail Pages:
Last modified 07 July 2025