About

2024-12-02 Added License to App environment

2024-11-30 Added Transaction and Undo to Data

2024-10-06 Added Query Object to Classes / Interfaces. Added Optimisitic Locking and Pessimistic Locking to Data

2024-09-28 Added Data synchronization to Data.

2024-04-21 Added Graphics Pipeline and Double Buffering to Presentation.

2024-04-13 Added Command Line Interface and Icon Set to Presentation.

2024-04-07 Added UTC, Standardized Date Format and UNICODE as a section "data formats" in Data.

2024-04-01 Added Snapshot Sequence.

2024-03-31 Added User Interface and User Experience to Presentation. I realize these are large fields in themselves, and it doesn't do justice to them to summarize these in some bullet points, but I just wanted to make a start.
I also added an entry on Explainability, a personal favorite of mine in my last projects.

2024-02-24 Added a section "Single purpose logic and software library" in Application logic, because I'm more and more convinced that this belongs to the essence of a maintainable application.

2023-09-16 Started the website. Collecting all kinds of patterns.

The site intends to help a software developer to build an application. All information is given from the perspective of the software developer. It aims to describe the most important patterns of software itself. Software development also has other aspects (investing, management, testing, user adoption, marketing, etc) but these are not addressed here.

This site aims to collect all known architectural patterns. However, many techniques may be considered an "architectural pattern", so it may be useful to define what is considered one on this site.

Architectural pattern

An architectural pattern is a specific generic system-wide organization or behaviour. It defines the main parts of the structure, and their interactions.

By calling it specific I exclude things like "natural language processing" or "domain driven design" because it is too broad, and it spans a large number of techniques. I just want to describe patterns that have a direct effect on the code. They're patterns of the system, not of its design or mindset.

By generic I mean that it is not bound to any application type. There are patterns that are unique to word processing, web development, embedded, etc, but this site is about the patterns that can be applied in many areas.

System-wide means that the pattern has an effect throughout the system, and not just within a single module.

The meaning of the word "pattern" used here comes closest to this one of the Cambridge Dictionary: "a particular way in which something is done or organized, or in which something happens" (source)

A system can be a complete application, but may also be, and often is, part of larger application. Note that the definition doesn't mention hardware, or even software, as these structures may be implemented in any way.

Like species in nature, software patterns can have varieties; a software pattern can be seen as a group of similar varieties. And like nature, a variety can be as similar to one pattern as it is to another. To which pattern does it belong? I tend to group the variety with both patterns, and you can pick the pattern that best meets your intent.

When is a variety sufficiently different from another to warrant a new pattern? To determine this we need a strong definition of the pattern. Hence I start every pattern with a definition. Next, a pattern has a prototypical form and some variants. A good rule-of-thumb to discern between two patterns would be to ask yourself if the software that matches the pattern can be easily changed into the other pattern.

Here are some concepts that occur in multiple patterns.

Dependency

Volatile dependencies are services that don't behave the same in all circumstances. Examples: database, file system, sending email, random number generator, current time. A file may not exist, disk may be full, email may not be sent, etc. The opposite of volatile is stable. A stable depenency is dependable: it behaves the same in all circumstances.

Client

A client is a software application that needs some functionality from a server, external to the client, to work properly.

Service

A software function performed by a server in response to a client request.

Server

A software application that provides a service.

Model

A model (domain model, business model) is the combination of data and domain logic software that governs the restrictions on this data.

Application logic

Domain logic that is application-specific

View

A view forms the presentation of data to the user and allows the user to enter information.

Presenter

The logic that prepares data to be shown in the (passive) view.

Controller

A controller processes incoming requests (made by the user, or by other software) by interacting with the model and updating the view.

Message

A piece of information that is published by a component to all subscribers, based on a specific event.

I once found myself as a software developer in a position where I was asked to build a new application, a virtual driving instructor. I had no idea how to approach this problem. I could just start building classes and functions and hope for the best, but I felt I needed to have an idea of the big picture of the application before I endeavoured the project. If I had the structure wrong, the program could be be arduous to complete and it could become unnecessarily slow. Furthermore, I would have no way to communicate to others about the structure of the application. I needed an architecture, before I started building. But I didn't have any examples to base it upon.

In 2003 I started a sub-site about architectural patterns, named "Garfixia Software Architectures", and hosted it on the domain I used for my Andreas fansite: https://www.dossier-andreas.net/software_architecture/index.html I had no idea people would be interested, but it actually became quite popular. Many people have used the simple diagrams for presentations, and there are even some references in published books.

Twenty years later I thought it would be good to modernize the site, update the contents, and give it a proper domain.

The span of the website expanded from "list all known architectural patterns", via "list all patterns that seem to have the same gist as these known patterns" to "categorize all patterns I see as architectural in scope", and ended up in "all application-wide software techniques and deliverables". The latter is still in line with the original aim: to help the software developer in their quest to create an original application.

I built this site to help software developers build an application. I have some experience in the field where I can draw upon, but I don't have personal experience with all patterns described here. It may contain errors. Also, the naming of patterns is not standardized, and different sources may name the same pattern differently. Finally, a number of remarks on this site may come across as my personal opinion, and for the moment I admit this is true. However, I intend to replace these with remarks from thought leaders in the field.

Best to treat this website as an index and a source of inspiration and follow the links provided for more in-depth in each subject.