Vyuh CDX

Philosophy

Core design principles and architectural decisions behind the Entity System

Philosophy of Entity-Driven Design

The Vyuh Entity System is built on a foundation of carefully considered design principles that prioritize consistency, modularity, and developer productivity. This document explores the core philosophy behind the system and the architectural decisions that shape its implementation.

Core Principles

1. Entity-First Architecture

At the heart of the Vyuh Entity System is the belief that business logic should be modeled as entities. An entity represents any business object that has:

  • A unique identity
  • A defined lifecycle
  • Relationships with other entities
  • Business rules and behaviors

By treating everything as an entity - from users and products to locations and equipment - we create a consistent mental model that scales across the entire application.

// Everything is an entity
class User extends EntityBase { ... }
class Location extends EntityBase { ... }
class Equipment extends EntityBase { ... }
class ReferenceStandard extends EntityBase { ... }

2. Configuration Over Code

The system embraces declarative configuration over imperative programming. Instead of writing repetitive CRUD controllers, UI screens, and API endpoints, developers define a single configuration that generates all necessary components:

final userConfig = EntityConfiguration<User>(
  metadata: userMetadata,
  api: userApi,
  layouts: userLayouts,
  form: userForm,
  actions: userActions,
);

This approach:

  • Reduces boilerplate code by 80-90%
  • Ensures consistency across all entities
  • Makes it easy to add new features system-wide
  • Simplifies maintenance and updates

3. Separation of Concerns

The entity system enforces clear boundaries between:

  • Data Models - Pure entity definitions with JSON serialization
  • Business Logic - API implementations and validation rules
  • Presentation - Layouts, forms, and UI components
  • Infrastructure - Routing, permissions, and services

This separation allows teams to work independently and makes the codebase more maintainable.

4. Composability and Extensibility

Every component is designed to be:

  • Composable - Mix and match layouts, forms, and actions
  • Extensible - Override default behavior when needed
  • Pluggable - Add custom implementations without modifying core
// Multiple layouts for different use cases
layouts: EntityLayoutDescriptor(
  list: [
    TableListLayout(...),    // Default table view
    GridListLayout(...),      // Card-based grid
    CustomMapLayout(...),     // Custom implementation
  ],
  details: [
    StandardDetailLayout(...),
    CompactDetailLayout(...),
  ],
);

5. Convention Over Configuration

While highly configurable, the system provides sensible defaults:

  • Standard CRUD routes (/users, /users/new, /users/:id)
  • Common UI patterns (tables, forms, detail views)
  • Default permissions (CRUD actions)
  • Standard API endpoints

Developers only need to specify deviations from these conventions.

Architectural Patterns

The Entity Configuration Pattern

Each entity is fully described by a single EntityConfiguration object that serves as the source of truth:

EntityConfiguration<T> {
  metadata,    // What is this entity?
  api,         // How do we interact with it?
  layouts,     // How do we display it?
  form,        // How do we edit it?
  actions,     // What can we do with it?
}

This pattern ensures that all entity-related code is co-located and discoverable.

The Provider Pattern

The entity system integrates seamlessly with Flutter's provider pattern:

EntityProvider.of<User>(context).list();
EntityProvider.of<User>(context).byId(userId);

This provides:

  • Type-safe access to entity operations
  • Automatic dependency injection
  • Reactive updates via ChangeNotifier

The Layout System

Layouts are first-class citizens, not afterthoughts:

abstract class EntityLayout<T> {
  Widget build(BuildContext context, List<T> entities);
  bool canHandle(BuildContext context);
}

This allows:

  • Multiple views of the same data
  • Context-aware layout selection
  • Easy addition of new visualizations

The Permission System

Security is built into every layer:

// Declarative permission checks
PermissionGuard(
  permissions: [Permission.read('users')],
  child: UserListView(),
)

// Programmatic checks
if (await hasPermission(Permission.update('users', userId))) {
  // Allow edit
}

Design Benefits

1. Rapid Development

By providing a complete framework for entity management, developers can:

  • Add new entities in minutes, not hours
  • Focus on business logic, not infrastructure
  • Leverage pre-built UI components
  • Avoid common pitfalls

2. Consistency

All entities behave the same way:

  • Same URL patterns
  • Same UI interactions
  • Same API structure
  • Same permission model

This consistency reduces cognitive load and improves user experience.

3. Maintainability

The declarative approach means:

  • Less code to maintain
  • Centralized configuration
  • Easy to understand entity behavior
  • Simple to add system-wide features

4. Scalability

The system scales in multiple dimensions:

  • Feature scaling - Add entities without increasing complexity
  • Team scaling - Clear patterns for parallel development
  • Performance scaling - Built-in pagination and lazy loading
  • UI scaling - Support for different screen sizes and layouts

5. Testability

The separation of concerns enables:

  • Unit testing of business logic
  • Widget testing of UI components
  • Integration testing of complete flows
  • Mock implementations for testing

Real-World Impact

In practice, this philosophy has enabled teams to:

  1. Reduce development time - What used to take days now takes hours
  2. Improve code quality - Consistent patterns reduce bugs
  3. Enhance user experience - Uniform behavior across the application
  4. Simplify onboarding - New developers are productive quickly
  5. Enable innovation - More time for unique features, less on boilerplate

Comparison with Traditional Approaches

Traditional MVC/MVVM Approach

// Lots of boilerplate for each entity
class UserController { ... }
class UserRepository { ... }
class UserListScreen { ... }
class UserDetailScreen { ... }
class UserEditScreen { ... }
class UserService { ... }

Entity System Approach

// Single configuration generates everything
final userConfig = EntityConfiguration<User>(...);
vyuh.entity.register(userConfig);

Future Evolution

The entity system philosophy is designed to accommodate future needs:

  • AI Integration - Entities provide structured data for AI operations
  • Real-time Sync - Entity pattern works well with real-time databases
  • Offline Support - Clear entity boundaries simplify offline strategies
  • Multi-platform - Same entity model across mobile, web, and desktop

Conclusion

The Vyuh Entity System represents a paradigm shift in how we build Flutter applications. By embracing entity-driven design, we create applications that are:

  • Easier to build
  • Simpler to maintain
  • More consistent for users
  • Faster to extend

The philosophy is simple: treat your business objects as first-class citizens, and the framework handles the rest. This approach has proven successful across multiple production applications and continues to evolve based on real-world usage.


Next: Getting Started - Build your first entity in 10 minutes!