Skip to content

Instantly share code, notes, and snippets.

@jaceklaskowski
jaceklaskowski / Rough Notes about CQRS and ES.md
Last active February 19, 2025 12:29
Rough Notes about CQRS and ES

Rough Notes about CQRS and ES

Once upon a time…

I once took notes (almost sentence by sentence with not much editing) about the architectural design concepts - Command and Query Responsibility Segregation (CQRS) and Event Sourcing (ES) - from a presentation of Greg Young and published it as a gist (with the times when a given sentence was heard).

I then found other summaries of the talk and the gist has since been growing up. See the revisions to know the changes and where they came from (aka the sources).

It seems inevitable to throw Domain Driven Design (DDD) in to the mix.

@zsup
zsup / ddd.md
Last active April 2, 2025 23:33
Documentation-Driven Development (DDD)

Documentation-Driven Development

The philosophy behind Documentation-Driven Development is a simple: from the perspective of a user, if a feature is not documented, then it doesn't exist, and if a feature is documented incorrectly, then it's broken.

  • Document the feature first. Figure out how you're going to describe the feature to users; if it's not documented, it doesn't exist. Documentation is the best way to define a feature in a user's eyes.
  • Whenever possible, documentation should be reviewed by users (community or Spark Elite) before any development begins.
  • Once documentation has been written, development should commence, and test-driven development is preferred.
  • Unit tests should be written that test the features as described by the documentation. If the functionality ever comes out of alignment with the documentation, tests should fail.
  • When a feature is being modified, it should be modified documentation-first.
  • When documentation is modified, so should be the tests.
@gitaarik
gitaarik / git_submodules.md
Last active April 22, 2025 19:46
Git Submodules basic explanation

Git Submodules basic explanation

Why submodules?

In Git you can add a submodule to a repository. This is basically a repository embedded in your main repository. This can be very useful. A couple of usecases of submodules:

  • Separate big codebases into multiple repositories.
#!/bin/bash
#Ensure we have the quantity specified on the CLI
if [ -z "$3" ]; then ARG_ERR=ERR; fi
if [ -z "$2" ]; then ARG_ERR=ERR; fi
if [ -z "$1" ]; then ARG_ERR=ERR; fi
if [ -n "$ARG_ERR" ];
then
echo "Usage: <filecount> <filenamebase> <filenameextension>"
exit