stopsopa.github.io/learn.html at master · stopsopa/stopsopa.github.io · GitHub

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta
      name="viewport"
      content="width=device-width, user-scalable=no, initial-scale=1.0, maximum-scale=1.0, minimum-scale=1.0"
    />

    <title>Learn - Development & Learning Resources</title>
  </head>
  <body class="layout bg" toc>
    <div class="body">
      <div class="inside">
        <div class="cards toc">
          <h1>Table of Contents</h1>
          <ul data-do-sort>
            <!--             <li><a href="http://">ekstra link</a></li> -->
          </ul>
        </div>
        <h2>Learn</h2>

        <script type="editor" data-lang="sh">

          https://www.solidqueue.co.uk/
          https://dev.37signals.com/solid-cache/
            // from: https://youtu.be/0rlATWBNvMw?t=2322

          Electron:
            https://palette.dev/blog/improving-performance-of-electron-apps
        </script>
        <h2>Functional programming</h2>

        <script type="editor" data-lang="sh">

          Data-Driven Functional Programming.
            https://github.com/stopsopa/WebMCompressor/tree/c48ff547fecc07343a85665eaaa44b617fa27fe0/electron/tools
        </script>
        <h2>DDD - Domain Driven Design</h2>

        <script type="editor" data-lang="sh">

          https://youtu.be/4rhzdZIDX_k
          https://martinfowler.com/bliki/DomainDrivenDesign.html
          Book: https://github.com/gmoral/Books/blob/master/Domain%20Driven%20Design%20Tackling%20Complexity%20in%20the%20Heart%20of%20Software%20-%20Eric%20Evans.pdf
            Domain Driven Design - Eric Evans

          DDD is contextual, not dogmatic.
          DDD is not a religion. It is a set of tools.
          DDD is not for every system
          DDD is not about purity
          DDD must respect technical constraints
          DDD becomes harmful when:
            People worship abstractions
            Ignore performance, tooling, or ops
            Over-model trivial domains
          DDD uses strong/atomic consistency wherever possible, and eventual consistency only where unavoidable.
          Over-large aggregates kill scalability: https://github.com/user-attachments/assets/43ad62c5-222e-4039-9c68-de5d7338ebbc

          Later experminet with :
            g(Translate my Symfony/Spring architecture to DDD terms)
            g(Show me a real use case where Evans-style is clearly better)

          Core Concepts
            Domain Model:
              A rich, abstract representation of the business logic, processes, and rules, central to the software design.
            Ubiquitous Language: [ju by quy tys]
              A common, shared vocabulary used by developers and domain experts to ensure everyone speaks the same language, reducing misunderstandings.
                Domain experts <-> Developers
                some members of the team manage to become bilingual, but they become bottlenecks of information flow
            Bounded Context:
              Bounded Contexts are intentional design boundaries, and they very often align with team boundaries, but not always
                That is usually though true because: Language is social, Models are maintained by people, Ownership matters
              A Bounded Context defines: A model, A language, A set of rules
                Inside it: consistency is mandatory
                Outside it: translation is mandatory
              More general:
                Teams should keep their own model and vocabulary consistent internally, and not force it on others.
              A clear boundary within which a specific domain model is consistent, preventing confusion across different parts of a large system (e.g., an "Order" context vs. a "Product Catalog" context).
              Large systems are broken into Bounded Contexts, each with its own specialized model, managed by patterns like the Anti-Corruption Layer for integration.
              są obszary w których dokonała się pewna stabilizacja (powszechne uzgodnienie) słownictwa i terminologii i dla wszystkich zapoznanych z tym obszarem istnieje ustalony/stabilny język porozumiewania się
              It might be encapsulated in microservice, module, package or team responsibility - what matters is clarity not technology.
              If a word needs explaining - 👉 you probably crossed a context boundary.
              A Bounded Context defines where a specific domain model and its language are valid—and protects it from other meanings.
              Good example: https://imgur.com/p441qP4 or https://github.com/user-attachments/assets/bab73640-c38d-4099-bb52-535d88b4efc1

          Context Map: https://github.com/user-attachments/assets/5ecc2aca-991b-49f0-9e92-19dbc504d1e4

            Strategic Design vs Tactical Design:
              Tactical DDD without Strategic DDD fails at scale.
              Strategic DDD without Tactical DDD becomes PowerPoint architecture.
            Strategic Design:
              Strategic Design (BIG PICTURE): Where are the boundaries, and who owns what?
              You usually do this: Early, With domain experts, With architects / leads
              Purpose: Defines boundaries, Protects teams, Prevents language collapse
              Concerns: Bounded Contexts, Context Maps, Team ownership, Language consistency
              Strategic design artifacts: Context Map, Bounded Context definitions, Integration contracts
              High-level organization of the domain, identifying core, supporting, and generic subdomains, and mapping relationships between them.
            Tactical Design:
              How do we model this context correctly?
              Purpose: Protects correctness, Encodes invariants, Survives change
              Concerns: Entities, Value Objects, Aggregates, Repositories, Domain Services, Domain Events
              You do this: Daily, In code, While implementing features
              Lower-level patterns for building the model within a Bounded Context, including:

                Rule:
                  Any business constraint or policy.
                    - Orders must be paid before shipping
                    - Notifications should be sent on cancellation
                    - Retry payment up to 3 times
                  As an extension: Rule categories:
                    Invariant -> Must always hold
                    Policy -> Desired behavior
                    Workflow rule -> Ordering / timing
                    Business process -> Coordination over time
                      So: Invariant = strongest rule -> If an invariant is violated, the system is broken.

                  Invariant: (special type of rule)  must be true now
                    If a rule spans multiple aggregates, it is not an invariant.
                    An invariant is: A rule that must be true immediately after every valid state change of an aggregate.
                      Example:
                        - An order cannot be shipped and cancelled - that cannot happen
                        - An order total must equal the sum of its line items
                        - An order cannot transition from SHIPPED → CANCELLED
                        - Account balance may never be negative
                        - Ledger entries must balance (debits = credits)
                        - A seat cannot be assigned to two passengers
                        - A booking cannot exceed capacity
                        - Email address must be unique
                        - User cannot have two active identities
                        - Only one active subscription per plan
                        - Cannot bill twice for the same period
                        - Stock count cannot go below zero
                        - Reserved quantity ≤ available quantity
                      False invarinats:
                        - ❌ “Customer must be refunded after cancellation”
                        - ❌ “Email must be sent”
                        - ❌ “Payment must succeed”
                          These involve: Time (something happens "eventually"), External systems, Failure, require retries, requires human intervention
                          Those are policies, workflows, or process rules — not invariants.
                    When it becomes "workflow guarantee" : https://github.com/user-attachments/assets/81498e57-c1d4-458e-85d3-f72b03977985
                Workflow:
                  - gets you from one valid state to another
                  - Long-running workflows are normal in real systems: minutes, hours days
                  - partial faiulre - normal
                  - retries - also normal, might be accounted in workflow design
                  - human involvment - also normal if cannot be avoided
                  - "All or nothing" - usually it's illusion
                  - avoid blocking calls in workflows
                  - eventual consistency - might be part of design, totally ok
                  - big transactions across system - avoid
                  - Rules about when things happen, not what is allowed
                  - A sequence of steps that coordinate actions over time, possibly across aggregates or systems.
                  - Decides when email is sent
                  - Decides when refund happens
                  - Coordinates multiple steps
                  - NOT: Decides whether cancellation is allowed - that would be Entity's responsibility RULE
                Saga:
                  workflow across aggregates
                Domain Event:
                  - represents something that happened in the domain that other parts of the system may care about
                  - not commands, not instructions, not workflows , but facts
                  - example: https://i.imgur.com/S1JU5Vx.png || https://github.com/user-attachments/assets/898dd06a-2bd6-4275-907b-20cc2f072fa6

                Entities: Mutable
                  Objects with a distinct identity (e.g., a specific Customer).
                    TEST:
                      “This is the same thing as before, even though it changed” - then this is entity
                      Created -> changed -> possibly retured - history matter? - probably entity
                  Entities usually: Guard transition, Enforce rules, Encapsulate state changes
                  Entities usually encapsulate rules that govern their own state and consistency
                  ===INVARIANTS=== (Always-True Rules) - An invariant is a specific kind of rule - strict, narrower
                  Entities encapsulate rules that protect their own state and invariants; other rules live elsewhere


                Value Objects: Immutable
                  Objects defined by their attributes, not identity (e.g., an Address).
                    TEST:
                      “This is just a different value now” - then this is value object
                      No history - just current values
                      $10 today is indistinguishable from $10 tomorrow - No identity - Equality by amount + currency therefore Immutable

                  IMPORTANT: Prefer Value objects - promote to Entity when domain demands identity
                Aggregates: enforcer of invariants
                  BEST DEFINITION: The smallest cluster of objects that must be consistent at all times. It's consistency boundary
                  why that name? Aggregates entities + value objects Under one transactional boundary To protect invariants
                  Aggregate borders start and end where from the business perspective the most desirable effect would be to have these operations executed atomically
                  Transactions should follow aggregates - not define them
                  When transaction spans across multiple calls to surrounding services — atomicity becomes impossible and business logic can get stuck in broken states.
                    But that is ok. Just make each aggregate consistent on its own.
                    In that case coordinate between aggregates asynchronously or via eventual consistency
                  enforces invariants atomically

                  Clusters of related entities and value objects treated as a single unit (e.g., an Order with its OrderItems).
                  Eventual consistency: (atomic consistency - ipposite)
                    - Eventual consistency is a consequence of protecting invariants
                    - Changes happen in separate transactions
                    - EC lays Between aggregates
                    - System may be temporarily inconsistent
                    - But guarantees convergence to a valid state
                    - Eventual consistency is not “sloppy consistency”. It is designed, constrained inconsistency.
                    - Opposite is strong consistency (transaction)
                    - Eventual consistency appears only when: Invariants span multiple aggregates Or multiple bounded contexts Or external systems
                    - honesty about time & failure
                Repositories:
                  For managing collection-like access to Aggregates.
                  Domain facing abstraction
                Domain Services:
                  For significant domain logic that doesn't fit naturally within an Entity or Value Object.
                Domain Events:
                  Notifications about something important that happened in the domain (e.g., "OrderPlaced").
              Anti-Corruption Layer:
                Prevent model "infection" -> Translates foreign models → your model
                where one context protects its model from another.
                Shields your domain from foreign concepts
                Acts as a firewall - language firewall
                ACL answers: "How do I keep their language from infecting my domain?”
                On the Strategic Design level: organizational and architectural questions
                It means: "We will integrate with that system, but on our terms." -> Billing →(ACL)→ Legacy Sales
                You can have strategic ACL without tactical discipline → model rot
                You can’t have tactical ACL without strategic intent → pointless wrappers

              Business Invariance - remains always true, no matter what
                (eg: product order total have to be sum of all product ordered)

          Benefits
            Better Alignment: Software stays tightly coupled with changing business needs.
            Improved Communication: A shared language reduces ambiguity.
            Maintainability: Complex logic is organized logically and predictably.
            Scalability: Helps manage complexity in large, evolving systems.

          Hexagonal Architecture:  https://youtu.be/bDWApqAUjEI
        </script>
      </div>
    </div>
    <script type="module" src="/js/github.js"></script>
  </body>
</html>