Enterprise
Enterprise, Business'ın ötesine geçen kuruluşlar için olan plandır: daha fazla takım üyesi, projeler ve istekler için katalog limiti yok ve sözleşmene göre ayarlanabilen limitler. Bu sayfa planın neleri içerdiğini, Mockomat'ın hesabını diğerlerinden nasıl ayırdığını ve domain modellemesini birden fazla takım arasında nasıl tutarlı tutacağını açıklar.
Enterprise'a geçiş
Enterprise çevrimiçi satın alınmaz, satış ekibimizle kararlaştırılır. Uygulamadaki Satışla konuş seçeneğini veya iletişim formunu kullan; fiyat talep üzerinedir.
Enterprise Neleri İçerir
- Business'taki her şey: API key'ler, takım rolleri, kod dışa aktarımı, endpoint analitiği.
- Projeler, çalışma alanları, aylık API istekleri, proje başına API key'ler, tablolar, attribute'lar, ilişkiler, işlemler ve pano notları için katalog limiti yok.
- 5'i yönetici olmak üzere en fazla 26 takım üyesi.
- Enterprise kod paketi: kod dışa aktarımı bir NestJS backend'i ve bir Angular ön ucu oluşturur (bkz. Dışa Aktarım).
- Sözleşmene göre ayarlanan limitler: ekibimiz hesabının limitlerini satış ekibiyle kararlaştırdığın değerlere göre ayarlar.
Diğer planların limitleri için Hesap ve Planlar sayfasına bak.
Hesap ve proje erişim modeline genel bakış.
Hesabın Nasıl Ayrılır
Enterprise, diğer tüm planlarla aynı platformu kullanır. Bu sınırlar her hesap için geçerlidir:
- Hesabın sınırdır. Projeler, modeller, üyeler, API key'ler ve plan limitleri hesabına aittir. Her istek hesabına göre kontrol edilir; böylece başka hesapların üyeleri senin projelerini açamaz.
- Üye başına proje erişimi. Yöneticiler hesabın tüm projelerini görür. Diğer üyeler, davet edilirken erişim verilen projeleri görür; isteğe bağlı proje bazlı bir geçersiz kılma rollerini kısıtlayabilir ama asla yükseltemez.
- Tüketici başına bir API key. Bir hesaptaki her proje, mock API'sinde yalnızca o projeye ait bir API key taşıyan isteklere yanıt verir. Key'ler her an iptal edilebilir.
- Ortak, salt okunur mock veriler. Mock API, ekibimizin içe aktardığı ve bakımını yaptığı Mockomat veri havuzundan satırlar sunar. İsteklerin yalnızca onu okur ve havuz her planda aynıdır. Kendi veri setlerini yükleyemezsin.
Hesap, proje ve veri sınırları.
Takım ve Roller
| Rol | Ne ekler |
|---|---|
| Salt Okunur | Projeleri, modeli ve veri önizlemesini görür; pano notlarını okur |
| Raportör | Pano notlarını ve yorumlarını yazar ve düzenler |
| Düzenleyici | Modeli kurar, proje oluşturur, API key'leri yönetir, kod dışa aktarımını çalıştırır |
| Yönetici | Projeleri siler, üyeleri ve proje erişimlerini yönetir, çalışma alanlarını yönetir |
Her rol, üstündeki rollerin her şeyini kapsar. Hesabın sahibi bir yöneticidir ve faturalandırmayı yönetir. Tam yetki listesi ve davet akışı için Team & Roles (İngilizce) sayfasına bak.
Takım üyesi yönetimi ve rol ataması.
Oturumlar ve Harici Tüketiciler
- Oturumlar: Enterprise'da hesap sahibi aynı anda birden fazla cihazda oturumunu açık tutabilir. Davet edilen üyeler bu olanağı katıldıkları hesaptan almaz: planı daha fazlasına izin veren kendi hesapları yoksa aynı anda yalnızca tek bir yerde oturum açık tutabilirler; başka bir yerde oturum açmak önceki oturumlarını sonlandırır. Herkesin oturumu, bir süre etkinlik olmadığında otomatik olarak kapatılır.
- API tüketicileri: mock API'ye yapılan her istek projeye ait bir API key taşır. Birini iptal ederken diğerlerine dokunmamak için her tüketici veya ortam (geliştirme, staging, CI) için ayrı bir key kullan.
- Actor token'ları (isteğe bağlı): bir tüketici, bir API key'in eş zamanlı kullanımının sınırlanabilmesi için bir actor token talep edebilir. Entegratörler sayfasındaki actor token bölümüne bak.
Yönetişim Modeli
Pratik bir yönetişim yaklaşımı, yeni takımlar katıldıkça domain modellemesini tutarlı tutar.
Alan Sahipliği
Her iş alanı için net bir sorumluluk ata:
- Alan sahibi — kendi alanındaki entity adlandırmasından, attribute tanımlarından ve ilişki stratejisinden sorumludur.
- İnceleyiciler — tüketiciler değişikliklere güvenmeden önce onları kontrol eden takım üyeleri (Raportör rolü uygundur).
- Tüketiciler — mock API'yi sorgulayan ancak modeli değiştirmeyen frontend geliştiricileri ve entegratörler (Salt Okunur rolü uygundur).
Ortak Adlandırma Kuralları
Kuruluş genelinde şunlar için standartlar belirle:
- Entity adlandırması — PascalCase, tekil isimler, iş dili (örneğin
Customer,customers_tbldeğil) - Attribute adlandırması — camelCase, açıklayıcı, kısaltmasız (örneğin
totalAmount,tot_amtdeğil) - İlişki adlandırması — net yön ve kardinalite
- İşlem adlandırması — liste işlemleri için tutarlı çoğul adlar, detay işlemleri için tekil adlar
Bu kurallara uyan bir referans projesi tut ve yeni projelere başlangıç noktası olarak Bir projeyi forkla ile kopyala.
İnceleme Geçitleri
| Aşama | İnceleme odağı | Kim inceler |
|---|---|---|
| Model değişikliği | Adlandırma tutarlılığı, attribute'ların eksiksizliği, ilişkilerin doğruluğu | Alan sahibi |
| API sunumu değişikliği | İşlemler, parametreler, sayfa boyutları | Alan sahibi + entegratör |
| Dışa aktarımdan önce | Runtime davranışı, parametreler, sıralama, ilişkiler | Alan sahibi + QA |
| Dışa aktarımdan sonra | Oluşturulan kod, modül sınırları, girdiler | Geliştirme ekibi lideri |
Hazırlık Kriterleri
Tüketiciler bir entity'ye bağımlı olmadan önce onun için "hazır"ın ne anlama geldiğini tanımla:
- Tüketicilerin ihtiyaç duyduğu her attribute, içe aktarılan verinin bir sütununa bağlıdır
- İlişkiler önizlemede çözülür
- İşlem parametreleri ve sıralama beklenen satırları döndürür
- Sayfalama temiz sayfa sınırları üretir
Modelleme ve runtime aşamalarında yönetişim kontrolleri.
Güvenlik
- Oturum açma: uygulama, her oturum için imzalı bir token kullanır. Çıkış yapmak, etkinliğin olmaması ve şifre değişikliği oturumları sunucuda sonlandırır.
- API key'ler: key'ler gizlidir. Onları sunucu tarafı koddan, CI'dan veya bir proxy üzerinden kullan — bir key'i asla frontend bundle'ına koyma — ve artık gerekmeyen bir key'i hemen iptal et.
- Şifreli trafik: uygulama ve mock API HTTPS üzerinden sunulur.
- Üretim verisi gerekmez: mock API'ler Mockomat veri havuzundan satırlar sunar; böylece test ortamların hiçbir zaman gerçek müşteri verisine ihtiyaç duymaz.
Güvenliğe genel bakış.
Operasyonel En İyi Uygulamalar
- Bir entity'yi bir takıma atamadan önce entity başına hazırlık kriterleri tanımla.
- İncelemelere runtime kontrollerini dahil et — tüketiciler bir değişikliğe güvenmeden önce önizlemeyi çalıştır.
- Kilometre taşlarında dışa aktar — oluşturulan kodu sürüm kontrolünde tut ve hangi model durumundan geldiğini not et.
- Kullanımı izle — işlemleri değiştirmeden önce tüketicilerin hangilerini çağırdığını endpoint analitiğinde gör.
- Düzenli olarak gözden geçir — domain tanımlarını değişen iş gereksinimleriyle uyumlu tut.
Kurumsal runtime doğrulaması ve operasyonel kontrol noktaları.