guardian/mobile-n10n
Logical Components
An overview of source code logical components.

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 20 components.

notificationworkerlambda3437 LOC (10%) 57 files
cdk1891 LOC (5%) 11 files
common1691 LOC (5%) 48 files
football1584 LOC (4%) 22 files
liveactivities1183 LOC (3%) 21 files
notification755 LOC (2%) 21 files
api-models681 LOC (2%) 9 files
registration648 LOC (2%) 21 files
schedulelambda367 LOC (1%) 6 files
eventconsumer326 LOC (1%) 9 files
fakebreakingnewslambda282 LOC (<1%) 7 files
ROOT265 LOC (<1%) 2 files
slomonitor179 LOC (<1%) 3 files
report173 LOC (<1%) 6 files
reportextractor132 LOC (<1%) 3 files
commoneventconsumer100 LOC (<1%) 4 files
commonEventBusPusher59 LOC (<1%) 1 file
commonscheduledynamodb58 LOC (<1%) 1 file
project33 LOC (<1%) 3 files
.github14 LOC (<1%) 1 file

scope details...
  • 256 files, 13,858 LOC (43.5% 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.
notificationworkerlambda452 commits (12%)
common412 commits (10%)
notification341 commits (9%)
registration266 commits (7%)
cdk176 commits (4%)
report143 commits (3%)
football98 commits (2%)
api-models64 commits (1%)
liveactivities56 commits (1%)
eventconsumer52 commits (1%)
fakebreakingnewslambda42 commits (1%)
schedulelambda38 commits (1%)
reportextractor29 commits (<1%)
commoneventconsumer29 commits (<1%)
slomonitor13 commits (<1%)
ROOT10 commits (<1%)
.github9 commits (<1%)
commonscheduledynamodb8 commits (<1%)
commonEventBusPusher3 commits (<1%)
project2 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 2019 2018 2017 2016 2015
cdk
145
11
4
16
football
63
3
9
7
7
9
liveactivities
56
registration
39
4
9
15
11
14
20
61
9
73
11
notificationworkerlambda
23
10
41
24
98
19
64
110
63
common
25
2
4
13
14
9
47
80
95
15
64
44
api-models
25
5
8
3
10
13
report
21
3
4
8
12
11
24
25
6
20
9
notification
17
4
15
28
11
5
87
88
9
51
26
ROOT
6
2
2
.github
6
3
fakebreakingnewslambda
6
1
10
6
3
16
commonEventBusPusher
3
project
1
1
reportextractor
1
4
4
3
3
14
eventconsumer
1
5
6
5
27
8
slomonitor
5
8
schedulelambda
1
9
10
3
3
8
4
commoneventconsumer
5
2
12
10
commonscheduledynamodb
4
3
1


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["liveactivities"]
    n1["football"]
    n2["api-models"]
    n3["registration"]
    n4["common"]
    n5["cdk"]
    n6["notificationworkerlambda"]
    n7["notification"]
    n8["commonEventBusPusher"]
    n9["project"]
    n0 ---|"30"| n0
    n1 ---|"28"| n1
    n2 ---|"16"| n1
    n3 ---|"12"| n4
    n0 ---|"10"| n5
    n6 ---|"10"| n6
    n0 ---|"9"| n1
    n0 ---|"8"| n2
    n5 ---|"6"| n1
    n4 ---|"5"| n4
    n7 ---|"4"| n4
    n2 ---|"4"| n2
    n8 ---|"3"| n1
    n4 ---|"3"| n6
    n8 ---|"3"| n0
    n7 ---|"2"| n6
    n7 ---|"2"| n7
    n5 ---|"2"| n2
    n8 ---|"2"| n5
    n6 ---|"1"| n5
    n3 ---|"1"| n1
    n3 ---|"1"| n2
    n3 ---|"1"| n0
    n3 ---|"1"| n3
    n5 ---|"1"| n5
    n4 ---|"1"| n1
    n4 ---|"1"| n2
    n6 ---|"1"| n1
    n6 ---|"1"| n2
    n9 ---|"1"| n5
    n9 ---|"1"| n0
    n9 ---|"1"| n2
    classDef default fill:#00b2ee,stroke:#ffffff,color:#000000;
    classDef highlighted fill:#00b2ee,stroke:#ffffff,color:#000000;
    linkStyle 0 stroke:#a0a0a0FF,stroke-width:10px
    linkStyle 1 stroke:#a0a0a0ED,stroke-width:9px
    linkStyle 2 stroke:#00688bA5,stroke-width:5px
    linkStyle 3 stroke:#00688b93,stroke-width:4px
    linkStyle 4 stroke:#00688b82,stroke-width:3px
    linkStyle 5 stroke:#a0a0a082,stroke-width:3px
    linkStyle 6 stroke:#00688b82,stroke-width:3px
    linkStyle 7 stroke:#00688b70,stroke-width:2px
    linkStyle 8 stroke:#00688b70,stroke-width:2px
    linkStyle 9 stroke:#a0a0a05E,stroke-width:1px
    linkStyle 10 stroke:#00688b5E,stroke-width:1px
    linkStyle 11 stroke:#a0a0a05E,stroke-width:1px
    linkStyle 12 stroke:#00688b5E,stroke-width:1px
    linkStyle 13 stroke:#00688b5E,stroke-width:1px
    linkStyle 14 stroke:#00688b5E,stroke-width:1px
    linkStyle 15 stroke:#00688b4C,stroke-width:1px
    linkStyle 16 stroke:#a0a0a04C,stroke-width:1px
    linkStyle 17 stroke:#00688b4C,stroke-width:1px
    linkStyle 18 stroke:#00688b4C,stroke-width:1px
    linkStyle 19 stroke:#00688b4C,stroke-width:1px
    linkStyle 20 stroke:#00688b4C,stroke-width:1px
    linkStyle 21 stroke:#00688b4C,stroke-width:1px
    linkStyle 22 stroke:#00688b4C,stroke-width:1px
    linkStyle 23 stroke:#a0a0a04C,stroke-width:1px
    linkStyle 24 stroke:#a0a0a04C,stroke-width:1px
    linkStyle 25 stroke:#00688b4C,stroke-width:1px
    linkStyle 26 stroke:#00688b4C,stroke-width:1px
    linkStyle 27 stroke:#00688b4C,stroke-width:1px
    linkStyle 28 stroke:#00688b4C,stroke-width:1px
    linkStyle 29 stroke:#00688b4C,stroke-width:1px
    linkStyle 30 stroke:#00688b4C,stroke-width:1px
    linkStyle 31 stroke:#00688b4C,stroke-width:1px
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:30