Skip to main content

Useful Abstractions

The following are simply links to useful abstractions (UAs) that may or may not be references by the guidelines for Hub. These are intended as reference material to facilitate understanding and are not a canonical list of UAs we implement in full or part within Hub or elsewhere.

Coupling and Cohesion

This may be the most important concept to understand. The holy grail in software design and architecture is high cohesion and low coupling. This is easier said than done.

Vertical Slices

Bounded Contexts

Domain Modeling

Clean/Hexagonal/Onion Architecture/Ports and Adapters

Task/Behaviors instead of CRUD

Persistence Agnosticism

Derived Types

Command Query Responsibility Separation (CQRS) + Command Query Separation (CQS)

Errors as Values

Distributed Systems

Domain Driven Design

Repository Pattern

Dependency Management (Tactical in code)

Additional Learning

High Optionality Programming

Article ~10 minute read

Video 22 min watch.

The earlier you are in a project's lifecycle, the more options you have and the less expensive they are then.. We should pay a premium here when the options are abundant and the cost is relatively low.

(Top Youtube Comment) The essence of architecture is at least as much about what changes are anticipated as it is about what is built. Every architectural choice you make is a bet on the relative likelihood of different changes in the future. How good a bet you can make a function of an understanding of core software design principles and experience in making (not avoiding) learning from the outcomes of bets.

Technical Debt is the Destruction of Options.

Examples of technical debt:

  • Tight coupling based on information cohesion causing issues when bumping into functional cohesion. The bloating of collections in mongo or tables in Hub, entity classes/types in Hub, or different modules in Zoho are good examples.
  • Tight coupling of unrelated concerns. There are cases where changing the alias of a column in a sql query or a field on a table would require changes all the way up to a React component.
  • Any of the data integrity issues we've had or STILL have and haven't resolved (school/term statuses, guide data, parent data, microschool data, etc.).
  • The lack of a single and independent Authorization capability to serve all consumers.
  • Not identifying the distinct stages of business processes and the owners for those stages.
  • Not identifying the life cycle of data within our system.
  • Building solutions to solve "this year's problems".

Green Field Projects

Greenfield Project? Start HERE! 13 min watch