Logical Decomposition #1: PRIMARY

The decompositions is based on the folder structure at level 1 (relative to the source code root).

Bubble Chart | Tree Map
Component Sizes (Lines of Code)
The "primary" logical decomposition has 13 components.

client9369 LOC (66%) 71 files
shared1147 LOC (8%) 45 files
cdk721 LOC (5%) 2 files
database-bridge-lambda593 LOC (4%) 6 files
bootstrapping-lambda567 LOC (4%) 10 files
users-refresher-lambda476 LOC (3%) 8 files
email-lambda439 LOC (3%) 4 files
grid-bridge-lambda291 LOC (2%) 3 files
ROOT146 LOC (1%) 6 files
workflow-bridge-lambda126 LOC (<1%) 1 file
archiver-lambda101 LOC (<1%) 2 files
notifications-lambda89 LOC (<1%) 2 files
auth-lambda29 LOC (<1%) 1 file

scope details...
  • 161 files, 14,094 LOC (100.0% vs. main code).
Component Commits
Components ordered by number of commits
Total Commits per Component
All commits, some commits may include files from multiple components.
client622 commits (46%)
shared198 commits (14%)
bootstrapping-lambda162 commits (12%)
database-bridge-lambda105 commits (7%)
cdk64 commits (4%)
ROOT62 commits (4%)
users-refresher-lambda52 commits (3%)
workflow-bridge-lambda43 commits (3%)
notifications-lambda36 commits (2%)
email-lambda29 commits (2%)
grid-bridge-lambda15 commits (1%)
auth-lambda13 commits (<1%)
archiver-lambda6 commits (<1%)
Yearly File Updates Trend per Components
The number of file changes in commits
animated commit history: all time cumulative | 12 months window
2026 2025 2024 2023 2022 2021 2020
client
4
41
39
155
277
93
13
shared
6
12
11
29
98
29
13
bootstrapping-lambda
4
12
8
11
72
37
18
cdk
6
10
22
26
database-bridge-lambda
6
7
5
19
68
users-refresher-lambda
6
4
6
26
10
email-lambda
4
5
20
ROOT
3
9
19
12
19
archiver-lambda
2
4
workflow-bridge-lambda
3
9
16
7
8
auth-lambda
3
6
4
grid-bridge-lambda
2
13
notifications-lambda
4
25
7


Dependencies between components in same commits (past 180 days)
The number on the lines shows the number of shared commits.
See detailed temporal dependencies report...

flowchart TB
    n0["bootstrapping-lambda"]
    n1["database-bridge-lambda"]
    n2["shared"]
    n3["users-refresher-lambda"]
    n0 ---|"4"| n0
    n1 ---|"4"| n0
    n2 ---|"4"| n0
    n2 ---|"4"| n1
    n3 ---|"4"| n0
    n3 ---|"4"| n1
    n3 ---|"4"| n2
    classDef default fill:#00b2ee,stroke:#ffffff,color:#000000;
    classDef highlighted fill:#00b2ee,stroke:#ffffff,color:#000000;
    linkStyle 0 stroke:#a0a0a093,stroke-width:4px
    linkStyle 1 stroke:#00688b93,stroke-width:4px
    linkStyle 2 stroke:#00688b93,stroke-width:4px
    linkStyle 3 stroke:#00688b93,stroke-width:4px
    linkStyle 4 stroke:#00688b93,stroke-width:4px
    linkStyle 5 stroke:#00688b93,stroke-width:4px
    linkStyle 6 stroke:#00688b93,stroke-width:4px

About This Analysis

Logical decomposition is a representation of the organization of the main source code, where every and each file is put in exactly one logical component.

  • A software system can have one or more logical decompositions.
  • A logical decomposition can be defined in two ways in Sokrates.
  • First approach is based on the folders structure. Components are mapped to folders at defined folder depth relative to the source code root.
  • Second approach is based on explicit definition of each component. In such explicit definitions, components are explicitly named and their files are selected based on explicitly defined path and content filters.
  • A logical decomposition is considered invalid if a file is selected into two or more components. This constraint is introduced in order to facilitate measuring of dependencies among components.
  • Files not assigned to any component are put into a special "Unclassified" component.


2026-10-07 12:35