Rodzina pojęć 01 · składanie modułów

Modularna architektura Open Mercato i granice pakietów

Open Mercato składa możliwości biznesowe z włączonych modułów i generowanych rejestrów. Kierunek zależności pakietów, jawne wymagania, stabilne klucze DI, granice edycji i odpowiedzialność aplikacji decydują, co można bezpiecznie zastąpić. Eject jest możliwy tylko dla zadeklarowanych modułów i przenosi odpowiedzialność za aktualizacje na zespół aplikacji.

Niezależność modułów wspiera wymienność, ale nie czyni każdej modyfikacji bezpieczną przy aktualizacji.

Migawka źródeł:

ae856df1ecfc · sekcje ARCHITECTURE.md: 3, 4, 6, 25, 26, 28, 29

Pozycja w systemie

Ta rodzina wyjaśnia, jak pakiety źródłowe stają się grafem włączonych modułów używanym przez aplikację hosta. Obejmuje składanie i granice, a nie decyzje architektoniczne konkretnego projektu.

Graf zależności pakietów i modułów

Shared znajduje się poniżej UI i Core; pakiety infrastruktury i providerzy udostępniają osobne kontrakty; aplikacja wybiera moduły i generowane połączenia.

Graf zależności pakietów i modułówShared znajduje się poniżej UI i Core; pakiety infrastruktury i providerzy udostępniają osobne kontrakty; aplikacja wybiera moduły i generowane połączenia.
01

Kod shared, UI, Core, infrastruktury, providerów, Enterprise i aplikacji zajmuje różne warstwy pakietów, a zależności kierują się w dół.

documented-convention

02

CLI wykrywa włączone moduły, zapisuje generowane rejestry i odrzuca brakujące zadeklarowane zależności podczas generowania.

oss-core

03

Usługi o zakresie żądania są rozwiązywane z kontenera Awilix przez stabilne klucze tekstowe.

oss-core

04

Moduły Enterprise są oddzielone źródłowo i włączane opcjonalnie; nie występują automatycznie w aplikacji OSS.

enterprise-opt-in

05

Samodzielna aplikacja włącza moduły pakietowe lub app-local i może użyć overrides albo UMES, zanim przejmie odpowiedzialność za kod po eject.

application-local

06

Generowane rejestry są artefaktami pochodnymi o osobnych lokalizacjach wersjonowanych i efemerycznych; ręczna edycja narusza odpowiedzialność generatora.

documented-convention

07

Możliwości biznesowe są rozdzielone między moduły Core i wspierające, a nie skupione w jednej nierozdzielnej warstwie aplikacji.

oss-core

Od modules.ts do działającego rejestru

Przebieg w czasie generowania ujawnia błąd zależności przed runtime.

  1. Samodzielna aplikacja włącza moduły pakietowe lub app-local i może użyć overrides albo UMES, zanim przejmie odpowiedzialność za kod po eject.

    documented-conventionapplication-local

  2. CLI wykrywa włączone moduły, zapisuje generowane rejestry i odrzuca brakujące zadeklarowane zależności podczas generowania.

    product-factoss-core

  3. Generowane rejestry są artefaktami pochodnymi o osobnych lokalizacjach wersjonowanych i efemerycznych; ręczna edycja narusza odpowiedzialność generatora.

    documented-conventiondocumented-convention

  4. Usługi o zakresie żądania są rozwiązywane z kontenera Awilix przez stabilne klucze tekstowe.

    documented-conventionoss-core

Kontrakty składania i odpowiedzialność

Kontrakty składania i odpowiedzialność
MechanizmWniosek redakcyjnyOgraniczenieWłaściciel decyzji
Kod shared, UI, Core, infrastruktury, providerów, Enterprise i aplikacji zajmuje różne warstwy pakietów, a zależności kierują się w dół.Traktuj jako kontrakt w zakresie „documented-convention” i osobno potwierdź dopasowanie do projektu.To zatwierdzona konwencja inżynieryjna. Własna aplikacja może ją naruszyć i wymaga osobnego przeglądu.Opiekun modułów i platformy
CLI wykrywa włączone moduły, zapisuje generowane rejestry i odrzuca brakujące zadeklarowane zależności podczas generowania.Traktuj jako kontrakt w zakresie „oss-core” i osobno potwierdź dopasowanie do projektu.Sam mechanizm nie dowodzi wydajności, bezpieczeństwa, dostępności, zgodności ani gotowości produkcyjnej konkretnego wdrożenia.Opiekun modułów i platformy
Usługi o zakresie żądania są rozwiązywane z kontenera Awilix przez stabilne klucze tekstowe.Traktuj jako kontrakt w zakresie „oss-core” i osobno potwierdź dopasowanie do projektu.To zatwierdzona konwencja inżynieryjna. Własna aplikacja może ją naruszyć i wymaga osobnego przeglądu.Opiekun modułów i platformy
Moduły Enterprise są oddzielone źródłowo i włączane opcjonalnie; nie występują automatycznie w aplikacji OSS.Traktuj jako kontrakt w zakresie „enterprise-opt-in” i osobno potwierdź dopasowanie do projektu.Ten element jest opcjonalny lub wymaga osobnej konfiguracji, dlatego nie należy przedstawiać go jako zawsze włączonego.Opiekun modułów i platformy
Samodzielna aplikacja włącza moduły pakietowe lub app-local i może użyć overrides albo UMES, zanim przejmie odpowiedzialność za kod po eject.Traktuj jako kontrakt w zakresie „application-local” i osobno potwierdź dopasowanie do projektu.To zatwierdzona konwencja inżynieryjna. Własna aplikacja może ją naruszyć i wymaga osobnego przeglądu.Opiekun modułów i platformy
Generowane rejestry są artefaktami pochodnymi o osobnych lokalizacjach wersjonowanych i efemerycznych; ręczna edycja narusza odpowiedzialność generatora.Traktuj jako kontrakt w zakresie „documented-convention” i osobno potwierdź dopasowanie do projektu.To zatwierdzona konwencja inżynieryjna. Własna aplikacja może ją naruszyć i wymaga osobnego przeglądu.Opiekun modułów i platformy
Możliwości biznesowe są rozdzielone między moduły Core i wspierające, a nie skupione w jednej nierozdzielnej warstwie aplikacji.Traktuj jako kontrakt w zakresie „oss-core” i osobno potwierdź dopasowanie do projektu.To zatwierdzona konwencja inżynieryjna. Własna aplikacja może ją naruszyć i wymaga osobnego przeglądu.Opiekun modułów i platformy

Footguns i tryby awarii

Moduły Enterprise są oddzielone źródłowo i włączane opcjonalnie; nie występują automatycznie w aplikacji OSS.

Ten element jest opcjonalny lub wymaga osobnej konfiguracji, dlatego nie należy przedstawiać go jako zawsze włączonego.

Sprawdź przypięte źródło

Generowane rejestry są artefaktami pochodnymi o osobnych lokalizacjach wersjonowanych i efemerycznych; ręczna edycja narusza odpowiedzialność generatora.

To zatwierdzona konwencja inżynieryjna. Własna aplikacja może ją naruszyć i wymaga osobnego przeglądu.

Sprawdź przypięte źródło
Źródła i metoda · 7 rekordów dowodowych

Każdy fakt, węzeł, połączenie i krok przebiegu ma stabilny identyfikator, klasę twierdzenia, lokalizator źródła, zakres, ograniczenie oraz przypiętą wersję. Lokalny skrypt sprawdza istnienie każdego pliku i lokalizatora oraz pokrycie sekcji 1–33 dokładnie raz.

  • Kod shared, UI, Core, infrastruktury, providerów, Enterprise i aplikacji zajmuje różne warstwy pakietów, a zależności kierują się w dół.

    ID
    section-03-monorepo-boundaries
    Klasa
    documented-convention
    Zakres
    documented-convention
    Źródło
    ARCHITECTURE.md · ## 3. Monorepo Structure
  • CLI wykrywa włączone moduły, zapisuje generowane rejestry i odrzuca brakujące zadeklarowane zależności podczas generowania.

    ID
    section-04-module-discovery
    Klasa
    product-fact
    Zakres
    oss-core
    Źródło
    packages/cli/src/lib/generators/module-registry.ts · export async function generateModuleRegistry
  • Usługi o zakresie żądania są rozwiązywane z kontenera Awilix przez stabilne klucze tekstowe.

    ID
    section-06-di-container
    Klasa
    documented-convention
    Zakres
    oss-core
    Źródło
    ARCHITECTURE.md · ## 6. Dependency Injection
  • Moduły Enterprise są oddzielone źródłowo i włączane opcjonalnie; nie występują automatycznie w aplikacji OSS.

    ID
    section-25-editions
    Klasa
    product-fact
    Zakres
    enterprise-opt-in
    Źródło
    ARCHITECTURE.md · ## 25. Editions: OSS and Enterprise
  • Samodzielna aplikacja włącza moduły pakietowe lub app-local i może użyć overrides albo UMES, zanim przejmie odpowiedzialność za kod po eject.

    ID
    section-26-standalone
    Klasa
    documented-convention
    Zakres
    application-local
    Źródło
    ARCHITECTURE.md · ## 26. Building a Standalone App
  • Generowane rejestry są artefaktami pochodnymi o osobnych lokalizacjach wersjonowanych i efemerycznych; ręczna edycja narusza odpowiedzialność generatora.

    ID
    section-28-generated-files
    Klasa
    documented-convention
    Zakres
    documented-convention
    Źródło
    packages/cli/src/lib/generators/module-registry.ts · addAutoGeneratedComment(sourceFile, 'registry')
  • Możliwości biznesowe są rozdzielone między moduły Core i wspierające, a nie skupione w jednej nierozdzielnej warstwie aplikacji.

    ID
    section-29-business-modules
    Klasa
    documented-convention
    Zakres
    oss-core
    Źródło
    ARCHITECTURE.md · ## 29. Business Modules Overview