Cześć! Jestem

Federico Calò

Sviluppatore Software | Divulgatore Tecnico

Creo applicazioni web moderne e strumenti digitali personalizzati per aiutare le attività a crescere attraverso l'innovazione tecnologica. La mia passione è unire informatica ed economia per generare valore reale.

Skontaktuj się

O Mnie

La mia passione per l'informatica è nata tra i banchi dell'Istituto Tecnico Commerciale di Maglie, dove ho scoperto il potere della programmazione e il fascino di creare soluzioni digitali. Fin da subito, ho capito che l'informatica non era solo codice, ma uno strumento straordinario per trasformare idee in realtà.

Durante gli studi superiori in Sistemi Informativi Aziendali, ho iniziato a intrecciare informatica ed economia, comprendendo come la tecnologia possa essere il motore della crescita per qualsiasi attività. Questa visione mi ha accompagnato all'Università degli Studi di Bari, dove ho conseguito la Laurea in Informatica, approfondendo le mie competenze tecniche e la mia passione per lo sviluppo software.

Oggi metto questa esperienza al servizio di imprese, professionisti e startup, creando soluzioni digitali su misura che automatizzano processi, ottimizzano risorse e aprono nuove opportunità di business. Perché la vera innovazione inizia quando la tecnologia incontra le esigenze reali delle persone.

Moje Umiejętności

Analisi Dati & Modelli Previsionali

Trasformo i dati in insights strategici con analisi approfondite e modelli predittivi per decisioni informate

Automatyzacja Procesów

Creo strumenti personalizzati che automatizzano operazioni ripetitive e liberano tempo per attività a valore aggiunto

Systemy Na Zamówienie

Sviluppo sistemi software su misura, dalle integrazioni tra piattaforme alle dashboard personalizzate

const federico = {
  nome: "Federico Calò",
  ruolo: "Sviluppatore Software",
  città: "Bari, Italia",
  missione: "Aiutare attraverso l'informatica",
  passioni: [
    "Codice Pulito",
    "Innovazione",
    "Crescita Continua"
  ]
};

Moja Misja

Credo fermamente che l'informatica sia lo strumento più potente per trasformare le idee in realtà e migliorare la vita delle persone.

Demokratyzacja Technologii

La mia missione è rendere l'informatica accessibile a tutti: dalle piccole imprese locali alle startup innovative, fino ai professionisti che vogliono digitalizzare la propria attività. Ogni realtà merita di sfruttare le potenzialità del digitale.

Łączenie IT i Biznesu

Non è solo questione di scrivere codice: è capire come la tecnologia possa generare valore reale. Intrecciando competenze informatiche e visione economica, aiuto le attività a crescere, ottimizzare processi e raggiungere nuovi traguardi di efficienza e redditività.

Tworzenie Rozwiązań na Miarę

Ogni attività è unica, e così devono esserlo le soluzioni. Sviluppo strumenti personalizzati che rispondono alle esigenze specifiche di ciascun cliente, automatizzando processi ripetitivi e liberando tempo per ciò che conta davvero: far crescere il business.

Przekształć Swój Biznes z Technologią

Che tu gestisca un negozio, uno studio professionale o un'azienda, posso aiutarti a sfruttare le potenzialità dell'informatica per lavorare meglio, più velocemente e in modo più intelligente.

Porozmawiajmy →

Unisciti alla Community

Entra nella community di sviluppatori dove discutiamo di software, AI, architettura e DevOps. Condividi idee, fai domande e cresci insieme a noi.

Canale

FC Dev Blog

Ricevi notifiche su nuovi articoli, serie complete, tips settimanali e tool in evidenza. Contenuti bilingui IT/EN direttamente nel tuo Telegram.

Nuovi articoli appena pubblicati
Tips e code snippets settimanali
Sondaggi sugli argomenti futuri

Iscriviti al Canale

Gruppo

FC Dev Community

Una community bilingue IT/EN per sviluppatori. Discussioni, Q&A, aiuto reciproco e networking con altri professionisti del settore.

Discussioni su articoli e tecnologie
Help coding e code review
Opportunità di lavoro e collaborazione

Unisciti al Gruppo

Topic di Discussione

Visualizza

Master SQL

RoadMap.sh

Novembre 2024

Visualizza

Oracle Certified Foundations Associate

Oracle

Ottobre 2024

Visualizza

People Leadership Credential

Connect

Settembre 2024

Linguaggi & Tecnologie

Java

Python

JavaScript

Angular

React

TypeScript

SQL

PHP

CSS/SCSS

Node.js

Docker

Git

💼

12/2024 - Presente

Custom Software Engineering Analyst

Accenture

Bari, Puglia, Italia · Ibrida Analisi e sviluppo di sistemi informatici attraverso l'utilizzo di Java e Quarkus in Health and Public Sector. Formazione continua su tecnologie moderne per la creazione di soluzioni software personalizzate ed efficienti e sugli agenti.

💼

06/2022 - 12/2024

Analista software e Back End Developer Associate Consultant

Links Management and Technology SpA

Esperienza nell'analisi di sistemi software as-is e flussi ETL utilizzando PowerCenter. Formazione completata su Spring Boot per lo sviluppo di applicazioni backend moderne e scalabili. Sviluppatore Backend specializzato in Spring Boot, con esperienza in progettazione di database, analisi, sviluppo e testing dei task assegnati.

💼

02/2021 - 10/2021

Programmatore software

Adesso.it (prima era WebScience srl)

Esperienza nell'analisi AS-IS e TO-BE, evoluzioni SEO ed evoluzioni website per migliorare le performance e l'engagement degli utenti.

🎓

2018 - 2025

Laurea in Informatica

Università degli Studi di Bari Aldo Moro

Bachelor's degree in Computer Science, focusing on software engineering, algorithms, and modern development practices.

📚

2013 - 2018

Diploma - Sistemi Informativi Aziendali

Istituto Tecnico Commerciale di Maglie

Technical diploma specializing in Business Information Systems, combining IT knowledge with business management.

Skontaktuj się

Masz projekt? Porozmawiajmy! Wypełnij formularz, a odpowiem wkrótce.

* Campi obbligatori. I tuoi dati saranno utilizzati solo per rispondere alla tua richiesta.

Architektura oparta na funkcjach z czystą architekturą we Flutter

W miarę rozwoju aplikacji Flutter czynnikiem decydującym staje się struktura kodu czynnikiem decydującym pomiędzy aplikacją, która się skaluje, a aplikacją, która gromadzi dług techniczny. Organizacja Najpierw funkcja — gdzie każdy katalog najwyższego poziomu reprezentuje plik a samodzielna funkcjonalność — i wzór przyjęty przez główne aplikacje Flutter dla przedsiębiorstw sukces w 2026 roku, w połączeniu z zasadami Czysta Architektura przez Roberta C. Martina, aby ściśle oddzielić obawy w ramach każdej funkcji.

W tym artykule zbudowano od podstaw kompletną architekturę: strukturę katalogów, implementacja trzech warstw (dane, domena, prezentacja), wstrzykiwanie zależności za pomocą Riverpod i strategie umożliwiające wyodrębnienie modułów i niezależnie testowane.

Czego się nauczysz

Najpierw funkcja a przede wszystkim warstwa: dlaczego ta pierwsza skaluje się lepiej w dużych zespołach
Trzy warstwy Czystej Architektury: dane, domena, prezentacja
Wzorzec repozytorium: Abstrakcyjny dostęp do danych za pomocą interfejsów Dart
Przypadek użycia (interaktor): Hermetyzuj logikę biznesową w testowalnych klasach
Wstrzykiwanie zależności za pomocą Riverpod: jak łączyć warstwy bez łączenia
Struktura katalogów dla korporacyjnego projektu Flutter
Testowanie warstwowe: domena testów jednostkowych, prezentacja testu widgetów
Jak wyodrębnić funkcję do osobnego pakietu Dart

Najpierw funkcja a przede wszystkim warstwa: podstawowe porównanie

Większość samouczków Fluttera organizuje kod według typu: models/, repositories/, screens/. Ta struktura pierwszej warstwy wygląda na całkiem małą, ale nie skaluje się.

# Layer-First (NON SCALABILE per progetti grandi)
lib/
  models/
    user.dart
    product.dart
    cart.dart
    order.dart
  repositories/
    user_repository.dart
    product_repository.dart
    cart_repository.dart
  screens/
    login_screen.dart
    product_list_screen.dart
    cart_screen.dart
  blocs/
    auth_bloc.dart
    product_bloc.dart
    cart_bloc.dart

# Problema: per aggiungere la feature "Cart" devi toccare
# 4 directory diverse. Impossibile estrarre il modulo.
# Team A e Team B modificano gli stessi file contemporaneamente.

# Feature-First (SCALABILE)
lib/
  features/
    auth/
      data/
      domain/
      presentation/
    products/
      data/
      domain/
      presentation/
    cart/
      data/
      domain/
      presentation/
  core/
    network/
    storage/
    theme/

# La feature "Cart" e completamente autonoma in lib/features/cart/
# Un team lavora su cart/ senza toccare le altre feature.
# In futuro: dart create --template=package cart e sposta la directory.

Anatomia cechy: trzy warstwy

W ramach każdej funkcji Clean Architecture narzuca trzy warstwy zależności jednokierunkowe: Prezentacja to zależy Domena, Data to zależy Domena, Ale Domena nie jest od nikogo zależna. Ta zasada jest sercem architektury.

# Struttura completa della feature "products"

lib/features/products/
  # DOMAIN LAYER: entita pure Dart, nessuna dipendenza esterna
  domain/
    entities/
      product.dart          # Entita del dominio (pure Dart class)
      product_filter.dart   # Value object per i filtri
    repositories/
      products_repository.dart  # Interfaccia (abstract class)
    usecases/
      get_products_usecase.dart    # Recupera lista prodotti
      search_products_usecase.dart # Cerca prodotti per query
      get_product_detail_usecase.dart

  # DATA LAYER: implementa le interfacce domain con source concrete
  data/
    models/
      product_dto.dart       # DTO: mappa JSON API -> entita domain
    sources/
      products_remote_source.dart  # HTTP calls
      products_local_source.dart   # SQLite / Hive cache
    repositories/
      products_repository_impl.dart # Implementa ProductsRepository

  # PRESENTATION LAYER: UI e state management
  presentation/
    providers/
      products_provider.dart       # Riverpod providers
    pages/
      products_list_page.dart
      product_detail_page.dart
    widgets/
      product_card.dart
      product_filter_bar.dart

Warstwa domeny: interfejs jednostki i repozytorium

# domain/entities/product.dart

// Entita: pure Dart, zero dipendenze da Flutter o pacchetti esterni
// Immutabile per convenzione (const constructor + final fields)
class Product {
  const Product({
    required this.id,
    required this.name,
    required this.price,
    required this.imageUrl,
    required this.category,
    this.description = '',
    this.rating = 0.0,
    this.inStock = true,
  });

  final String id;
  final String name;
  final double price;
  final String imageUrl;
  final String category;
  final String description;
  final double rating;
  final bool inStock;

  // copyWith: aggiorna campi mantenendo l'immutabilita
  Product copyWith({
    String? id,
    String? name,
    double? price,
    String? imageUrl,
    String? category,
    String? description,
    double? rating,
    bool? inStock,
  }) {
    return Product(
      id: id ?? this.id,
      name: name ?? this.name,
      price: price ?? this.price,
      imageUrl: imageUrl ?? this.imageUrl,
      category: category ?? this.category,
      description: description ?? this.description,
      rating: rating ?? this.rating,
      inStock: inStock ?? this.inStock,
    );
  }

  @override
  bool operator ==(Object other) =>
      identical(this, other) ||
      other is Product && runtimeType == other.runtimeType && id == other.id;

  @override
  int get hashCode => id.hashCode;
}

// domain/repositories/products_repository.dart

// Interfaccia: il Domain layer definisce IL CONTRATTO
// Il Data layer lo implementa. Il Domain non sa COME vengono presi i dati.
abstract interface class ProductsRepository {
  Future<List<Product>> getProducts({
    String? category,
    int page = 1,
    int limit = 20,
  });

  Future<Product> getProductById(String id);

  Future<List<Product>> searchProducts(String query);

  Future<void> refreshCache();
}

Warstwa domeny: przypadek użycia

Przypadki użycia (lub interakcje) obejmują pojedynczą akcję logiki biznesowej. jestem małe, testowalne klasy z pojedynczą rozliczalnością. Jeśli przypadek użycia rośnie za dużo i sygnał, który należy rozdzielić.

# domain/usecases/get_products_usecase.dart

import 'package:my_app/features/products/domain/entities/product.dart';
import 'package:my_app/features/products/domain/repositories/products_repository.dart';

// Parametri del Use Case: value object per type safety
class GetProductsParams {
  const GetProductsParams({
    this.category,
    this.page = 1,
    this.limit = 20,
  });

  final String? category;
  final int page;
  final int limit;
}

// Use Case: dipende SOLO dall'interfaccia repository (domain)
// Non sa nulla di HTTP, Dio, SQLite o Riverpod
class GetProductsUseCase {
  const GetProductsUseCase(this._repository);

  final ProductsRepository _repository;

  Future<List<Product>> call(GetProductsParams params) {
    return _repository.getProducts(
      category: params.category,
      page: params.page,
      limit: params.limit,
    );
  }
}

// Test del Use Case: zero dipendenze da Flutter
// test/features/products/domain/get_products_usecase_test.dart
class MockProductsRepository extends Mock implements ProductsRepository {}

void main() {
  late GetProductsUseCase useCase;
  late MockProductsRepository mockRepo;

  setUp(() {
    mockRepo = MockProductsRepository();
    useCase = GetProductsUseCase(mockRepo);
  });

  test('chiama repository con i parametri corretti', () async {
    // Arrange
    const params = GetProductsParams(category: 'electronics', page: 2);
    when(() => mockRepo.getProducts(
      category: 'electronics',
      page: 2,
      limit: 20,
    )).thenAnswer((_) async => []);

    // Act
    await useCase(params);

    // Assert
    verify(() => mockRepo.getProducts(
      category: 'electronics',
      page: 2,
      limit: 20,
    )).called(1);
  });
}

Warstwa danych: implementacja DTO i repozytorium

# data/models/product_dto.dart

// DTO (Data Transfer Object): sa come mappare JSON <-> entita domain
// Dipende dal domain (Product entity) ma non viceversa
class ProductDto {
  const ProductDto({
    required this.id,
    required this.name,
    required this.price,
    required this.imageUrl,
    required this.category,
    this.description,
    this.rating,
    this.inStock,
  });

  final String id;
  final String name;
  final double price;
  final String imageUrl;
  final String category;
  final String? description;
  final double? rating;
  final bool? inStock;

  // Factory: converte Map JSON in DTO
  factory ProductDto.fromJson(Map<String, dynamic> json) {
    return ProductDto(
      id: json['id'] as String,
      name: json['name'] as String,
      price: (json['price'] as num).toDouble(),
      imageUrl: json['image_url'] as String,
      category: json['category'] as String,
      description: json['description'] as String?,
      rating: (json['rating'] as num?)?.toDouble(),
      inStock: json['in_stock'] as bool?,
    );
  }

  // toEntity: converte DTO in entita domain
  Product toEntity() {
    return Product(
      id: id,
      name: name,
      price: price,
      imageUrl: imageUrl,
      category: category,
      description: description ?? '',
      rating: rating ?? 0.0,
      inStock: inStock ?? true,
    );
  }
}

# data/repositories/products_repository_impl.dart

class ProductsRepositoryImpl implements ProductsRepository {
  const ProductsRepositoryImpl({
    required this.remoteSource,
    required this.localSource,
  });

  final ProductsRemoteSource remoteSource;
  final ProductsLocalSource localSource;

  @override
  Future<List<Product>> getProducts({
    String? category,
    int page = 1,
    int limit = 20,
  }) async {
    try {
      // Prima prova la cache locale
      final cached = await localSource.getProducts(
        category: category,
        page: page,
        limit: limit,
      );
      if (cached.isNotEmpty) {
        return cached.map((dto) => dto.toEntity()).toList();
      }

      // Se la cache e vuota, chiama l'API remota
      final dtos = await remoteSource.getProducts(
        category: category,
        page: page,
        limit: limit,
      );

      // Salva in cache per la prossima volta
      await localSource.saveProducts(dtos);

      return dtos.map((dto) => dto.toEntity()).toList();
    } catch (e) {
      throw ProductsException('Impossibile caricare i prodotti: $e');
    }
  }

  @override
  Future<Product> getProductById(String id) async {
    final dto = await remoteSource.getProductById(id);
    return dto.toEntity();
  }

  @override
  Future<List<Product>> searchProducts(String query) async {
    final dtos = await remoteSource.searchProducts(query);
    return dtos.map((dto) => dto.toEntity()).toList();
  }

  @override
  Future<void> refreshCache() => localSource.clearAll();
}

Wstrzykiwanie zależności za pomocą Riverpoda

Riverpod to klej, który łączy trzy warstwy bez bezpośredniego łączenia: każdy dostawca deklaruje swoje zależności poprzez ref.watch tj Riverpod rozwiązuje cały wykres zależności w sposób leniwy i bezpieczny dla typu.

# presentation/providers/products_provider.dart

import 'package:riverpod_annotation/riverpod_annotation.dart';

part 'products_provider.g.dart';

// DATA LAYER providers
@riverpod
ProductsRemoteSource productsRemoteSource(Ref ref) {
  return ProductsRemoteSource(dio: ref.watch(dioProvider));
}

@riverpod
ProductsLocalSource productsLocalSource(Ref ref) {
  return ProductsLocalSource(db: ref.watch(databaseProvider));
}

// DOMAIN LAYER providers
@riverpod
ProductsRepository productsRepository(Ref ref) {
  return ProductsRepositoryImpl(
    remoteSource: ref.watch(productsRemoteSourceProvider),
    localSource: ref.watch(productsLocalSourceProvider),
  );
}

@riverpod
GetProductsUseCase getProductsUseCase(Ref ref) {
  return GetProductsUseCase(ref.watch(productsRepositoryProvider));
}

// PRESENTATION LAYER: AsyncNotifier che usa il use case
@riverpod
class ProductsList extends _$ProductsList {
  @override
  Future<List<Product>> build({String? category}) async {
    return ref.watch(getProductsUseCaseProvider).call(
      GetProductsParams(category: category),
    );
  }

  Future<void> refresh() async {
    await ref.read(productsRepositoryProvider).refreshCache();
    ref.invalidateSelf();
  }
}

// Nel widget: nessun accoppiamento con i layer sottostanti
class ProductsListPage extends ConsumerWidget {
  const ProductsListPage({super.key});

  @override
  Widget build(BuildContext context, WidgetRef ref) {
    final productsAsync = ref.watch(productsListProvider());

    return Scaffold(
      appBar: AppBar(title: const Text('Prodotti')),
      body: productsAsync.when(
        loading: () => const Center(child: CircularProgressIndicator()),
        error: (e, _) => Center(child: Text('Errore: $e')),
        data: (products) => ListView.builder(
          itemCount: products.length,
          itemBuilder: (context, i) => ProductCard(product: products[i]),
        ),
      ),
    );
  }
}

Testowanie według warstwy

Czysta architektura umożliwia optymalną strategię testowania: każda warstwa ma własny typ testu z minimalną niezbędną konfiguracją.

# Struttura test allineata alla struttura feature

test/
  features/
    products/
      domain/
        get_products_usecase_test.dart  # Unit test puri (no Flutter)
        product_entity_test.dart
      data/
        product_dto_test.dart           # Unit test con JSON fixtures
        products_repository_impl_test.dart # Mock remote + local source
      presentation/
        products_list_page_test.dart    # Widget test con provider override

# Widget test con override del provider per mock
testWidgets('Mostra lista prodotti', (tester) async {
  await tester.pumpWidget(
    ProviderScope(
      overrides: [
        // Override del use case con dati mock
        getProductsUseCaseProvider.overrideWithValue(
          FakeGetProductsUseCase(products: [
            const Product(
              id: '1',
              name: 'iPhone 15',
              price: 999.0,
              imageUrl: 'https://example.com/iphone.jpg',
              category: 'electronics',
            ),
          ]),
        ),
      ],
      child: const MaterialApp(home: ProductsListPage()),
    ),
  );

  await tester.pumpAndSettle();

  // Verifica che il prodotto mock sia visibile
  expect(find.text('iPhone 15'), findsOneWidget);
  expect(find.text('999.00 EUR'), findsOneWidget);
});

class FakeGetProductsUseCase extends Fake implements GetProductsUseCase {
  FakeGetProductsUseCase({required this.products});
  final List<Product> products;

  @override
  Future<List<Product>> call(GetProductsParams params) async => products;
}

Kiedy wyodrębnić funkcję z pakietu

Gdy funkcja jest ponownie wykorzystywana w wielu aplikacjach (np. auth wspólne pomiędzy aplikacja konsumencka i administracyjna) i czas stworzyć osobny pakiet Dart: dart create --template=package packages/auth_feature. Czysty Architektura sprawia, że to wyodrębnianie jest prawie mechaniczne: kopiujesz katalog funkcję w nowym pakiecie i zaktualizuj import. Zero refaktoryzacji architektury.

Wnioski

Architektura oparta na funkcjach i czysta architektura nie jest najprostszym rozwiązaniem dla małej aplikacji — i właściwe rozwiązanie dla aplikacji, która musi się rozwijać i ewoluować i przetrwać zmianę drużyn. Początkowy koszt konfiguracji (struktura katalogów, interfejsy, DTO, przypadki użycia) szybko się amortyzują: każda nowa funkcja następuje ten sam schemat, każdy programista wie dokładnie, gdzie znaleźć i gdzie umieścić kod, a każdą warstwę można niezależnie przetestować i wymienić.

W 2026 r. najbardziej niezawodne aplikacje Flutter dla przedsiębiorstw — od Nubanku, przez eBay, po ByteDance — wszystkie zbiegają się w kierunku wariantów tej struktury. To nie trend: to odpowiedź przećwicz prawdziwe problemy, które pojawiają się, gdy Flutter skaluje się poza 3-osobowy zespół.