Supported by
Create structurally and algorithmically complex, causality driven, asymmetric non-linear, scalable, topological, data abstracted and evolving systems.
means your software is built on the well-known thinking of cause and effect.
means your software is not forced into sequence by functional thinking.
Unlike numerical simulations it is also not forced into symmetric iterative execution. Still diverse and even fractal processing symmetry is possible by defining the meaning of systems time. Still there might be meaningful systems not requiring a symmetric meaning of time.
means your software will utilize given processing environment as allowed by configuration and inner relations.
means your software consists of elements related and configured as described in loaded JSON configuration.
means your algorithms do not know and do not care if given data is persisted and what technology is behind.
However, data needs to be MessagePack serializable for getting persisted when configured.
means your software might adapt it's topology to its environmental and evolving needs.
Initial topology is like a seed.
A discrete piece of data stored into memory is called an "Aspect". The thing about aspects is, they are managed by a ref counting borrowing pattern.
A borrowing pattern means, before you can access the memory you have to lock it to a scope. This borrow pattern ensures there are no concurrent mutable accesses to protected memory. However immutable accesses can be concurrent.
This memory protection is realized by a so called "Essence". It manages its atomic lock state.
An "Essence" can be referenced by multiple ref tracking/counting "References".
A "Tick" is a procedure taking in/out parameters triggering consecutive Ticks. An "Act" is a "Tick" set into an execution context.
A "Wirks" is a meaningful set of Ticks and their contextual requirements.
Discrete algorithm's execution order is given by "Branches". Branches are thread safe.
Processes/Ticks "Branch"(es). "Dispatcher" are thread safe.
Each "Aspect" can relate to other "Aspect"s through so called "Facet"s. A facet defines how an "Aspect" can interact. While relational information could also be stored at runtime just in the happening "Wirkung" a topology should always rely on properly defined "Facet"s except you have very certain intentions beyond.