Architecture

Ziegel is a modular library ecosystem built on TypeScript. Each library is a self-contained package that can be composed into any application independently. The libraries enforce strict boundaries between business logic and infrastructure through well-defined contracts.

Key Patterns

Dependency Inversion

All inter-library contracts use interfaces and abstract classes. Concrete implementations are injected at runtime via Angular's dependency injection system. This decouples library consumers from specific implementations and makes every service testable in isolation.

Single Responsibility

Each library owns exactly one domain concern. ziegel-platform-caching handles caching, ziegel-platform-logging handles logging, ziegel-platform-http handles HTTP — they never overlap. This means you only pull in what you need, and changes in one domain don't cascade across unrelated packages.

Tree-shakeable ESM

Every library is ESM-first with side-effect-free exports. Unused symbols are eliminated at build time. The barrel exports (index.ts) are the only public surface — internal modules are never exposed.

Signal-first State

State management prefers Angular signals and computed() over imperative patterns. ziegel-rx provides reactive utilities for cases where observables are required, and ziegel-redux offers Redux-based state management for complex application state.

Convention-based Mapping

ziegel-platform-mapping provides a centralized object-to-object mapper. Mapping profiles define transformations declaratively, keeping conversion logic out of services and controllers. This is the same pattern used across the platform for consistent data transformation.

---

Dependency Graph

                    ┌──────────────────┐
                    │   ziegel-core    │  (Foundation)
                    └────────┬─────────┘
                             │
        ┌────────────────────┼──────────────────────┐
        │                    │                       │
        ▼                    ▼                       ▼
┌───────────────┐  ┌─────────────────┐  ┌───────────────────┐
│ ziegel-data   │  │ ziegel-intl     │  │ ziegel-rx         │
│ (Repository)  │  │ (i18n Core)     │  │ (Rx Utilities)    │
└───────────────┘  └────────┬────────┘  └───────────────────┘
                            │
                ┌───────────┼───────────┐
                │                       │
                ▼                       ▼
      ┌─────────────────┐  ┌───────────────────┐
      │ ziegel-intl-    │  │ ziegel-intl-      │
      │ commerce        │  │ units             │
      └─────────────────┘  └───────────────────┘

                    ┌──────────────────┐
                    │ ziegel-platform  │  (Platform Foundation)
                    └────────┬─────────┘
                             │
    ┌──────────┬──────────┬──┴──┬──────────┬──────────┐
    │          │          │     │          │          │
    ▼          ▼          ▼     ▼          ▼          ▼
┌────────┐┌────────┐┌────────┐┌────────┐┌────────┐┌────────┐
│caching ││config  ││http    ││logging ││mapping ││messag- │
│        ││uration ││        ││        ││        ││ing     │
└────────┘└────────┘└────────┘└────────┘└────────┘└────────┘
    ┌──────────┬──────────┬──────────┬──────────┐
    │          │          │          │          │
    ▼          ▼          ▼          ▼          ▼
┌────────┐┌────────┐┌────────┐┌────────┐┌────────┐
│naviga- ││presen- ││serial- ││trans-  ││trans-  │
│tion    ││tation  ││ization ││action  ││lation  │
└────────┘└────────┘└────────┘└────────┘└────────┘

Standalone (core only):
┌───────────────┐  ┌───────────────┐  ┌─────────────────┐
│ ziegel-       │  │ ziegel-redux  │  │ ziegel-         │
│ presentation  │  │               │  │ localization    │
└───────────────┘  └───────────────┘  └─────────────────┘

---

Design Rules

1. ziegel-core has no Ziegel dependencies — it is the foundation that everything else builds on.
2. No horizontal dependencies — libraries at the same layer never depend on each other.
3. Dependencies flow downward — higher-layer libraries depend only on lower layers and core.
4. No circular dependencies — enforced structurally, not by convention.
5. Contracts use interfaces and abstract classes — serving as both type contract and DI token.
6. No global state — every service is explicitly configured at registration time.
7. No leaking internals — only symbols exported from the package barrel are considered public API.
8. ESM-only — all packages target ESM with side-effect-free exports for optimal tree-shaking.