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
Odpowiedź bezpośrednia
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.
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
→CLI wykrywa włączone moduły, zapisuje generowane rejestry i odrzuca brakujące zadeklarowane zależności podczas generowania.
oss-core
→Usługi o zakresie żądania są rozwiązywane z kontenera Awilix przez stabilne klucze tekstowe.
oss-core
→Moduły Enterprise są oddzielone źródłowo i włączane opcjonalnie; nie występują automatycznie w aplikacji OSS.
enterprise-opt-in
→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
→Generowane rejestry są artefaktami pochodnymi o osobnych lokalizacjach wersjonowanych i efemerycznych; ręczna edycja narusza odpowiedzialność generatora.
documented-convention
→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.
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
CLI wykrywa włączone moduły, zapisuje generowane rejestry i odrzuca brakujące zadeklarowane zależności podczas generowania.
product-factoss-core
Generowane rejestry są artefaktami pochodnymi o osobnych lokalizacjach wersjonowanych i efemerycznych; ręczna edycja narusza odpowiedzialność generatora.
documented-conventiondocumented-convention
Usługi o zakresie żądania są rozwiązywane z kontenera Awilix przez stabilne klucze tekstowe.
documented-conventionoss-core
Kontrakty składania i odpowiedzialność
| Mechanizm | Wniosek redakcyjny | Ograniczenie | Wł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łoGenerowane 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