Software architecture documentation


🚧 This section is still in active development and is subject to changes 🚧


The core purpose of writing this architecture documentation is to be able to describe to ourselves and others what Seedcase is aiming to accomplish and how it will do that.

We structured the software architecture documentation to follow the arc42 template and the C4 Model as much as is relevant for our situation, since these both are fairly popular and common templates to use. This documentation is also continuously evolving as we learn, test, develop, and grow as a team.


The assumed readers are similar to the ones we listed in the Design of Seedcase landing page. The complete list of expected readers is found in the Stakeholders section of the Introduction.

Section overview

  1. Introduction and goals: Targeted at any reader. Introduction to the architecture documentation, goals, core functionality requirements, guiding principles and philosophies, and stakeholders (readers of the documentation).
  2. Constraints: Targeted at any reader. Covers barriers or constraints we have self-imposed (for instance, due to ideological or philosophical reasons) as well as those we have no control over (such as technological server environments that Seedcase may be installed on).
  3. Context and scope: Targeted at any reader. Covers who our target or anticipated users are for Seedcase as well as potential technological “users” are, for instance, external servers connecting to Seedcase.
  4. Solution strategy: Targeted at any reader. Describes our proposed solution for the problem we are trying to address, as well as which core technologies and architecture designs we will use for the solution.
  5. Building block view: This is the most detailed section. The first part (Level 1) is targeted at readers who are more interested in some more technical details while later sections are much more highly detailed and written for those with much more technical knowledge. We describe the core architecture of Seedcase with increasing detail throughout the section, including the different parts and connections between parts.
  6. Runtime view: Targeted at readers who are interested in very technical details. Covers how the different parts will actually interact with each other when a user uses Seedcase.
  7. Deployment view: Targeted at readers who are interested in very technical details.
  8. Cross-cutting concepts: Targeted at both technical and non-technical users. Includes concepts such as security, privacy, legal considerations, storage, and dissemination.
  9. Architecture decisions: Targeted at technical readers. Covers the reasons for decisions we make about specific technologies or patterns used.
  10. Quality requirements: Targeted at any reader. This section goes into more detail on the quality goals listed in the introduction section.
  11. Risks and technical debt: Targeted at more technical readers, but includes content for non-technical readers. Describes potential risks with our solution, such as security risks.