DEV Community: nikosst

Fake και Mock στα Unit Tests με παραδείγματα και Clean Architecture

nikosst — Wed, 21 Oct 2026 13:05:05 +0000

Γράφουμε ένα unit test. Ο κώδικάς μας χρησιμοποιεί ένα repository, μια βάση δεδομένων ή μια υπηρεσία ειδοποιήσεων.

Και κάπου εκεί εμφανίζεται η ερώτηση:

Να χρησιμοποιήσω fake ή mock; Ποια είναι η διαφορά και ποιο κάνει καλύτερο το test μου;

Ένα fake μάς δίνει μια απλοποιημένη υλοποίηση που λειτουργεί. Ένα mock μάς επιτρέπει να επαληθεύσουμε συγκεκριμένες κλήσεις προς έναν συνεργάτη.

Η επιλογή εξαρτάται από αυτό που θέλουμε να αποδείξουμε:

Αν ενδιαφερόμαστε για το αποτέλεσμα μιας αλλαγής, ένα fake συχνά κάνει το test πιο φυσικό.
Αν ενδιαφερόμαστε για μια συγκεκριμένη εξωτερική ενέργεια, ένα mock μπορεί να εκφράζει ακριβώς την απαίτηση.
Αν μια πραγματική υλοποίηση είναι ήδη απλή, γρήγορη και προβλέψιμη, μπορούμε να τη χρησιμοποιήσουμε απευθείας.

Ας δούμε τι σημαίνουν αυτά, πάνω στο ίδιο παράδειγμα. Ο κώδικας χρησιμοποιεί Python 3.10+ και το ενσωματωμένο unittest, χωρίς επιπλέον βιβλιοθήκες. Οι αρχές εφαρμόζονται και σε άλλες γλώσσες και frameworks.

Τι ελέγχει ένα unit test

Ένα unit test ελέγχει μια συγκεκριμένη συμπεριφορά μιας μικρής μονάδας λογισμικού.

Η μονάδα μπορεί να είναι μια συνάρτηση, μια κλάση ή ένα μικρό σύνολο αντικειμένων που συνεργάζονται. Δεν υπάρχει ένας καθολικά αποδεκτός κανόνας ότι «ένα unit test επιτρέπεται να εκτελεί μόνο μία κλάση». Ο Martin Fowler περιγράφει τόσο tests με πραγματικούς συνεργάτες όσο και tests που τους αντικαθιστούν με test doubles. Unit Test — Martin Fowler

Για παράδειγμα, σε μια εφαρμογή διαχείρισης εργασιών, διαφορετικές συμπεριφορές είναι:

Μια ανολοκλήρωτη εργασία γίνεται ολοκληρωμένη.
Η νέα κατάσταση αποθηκεύεται.
Στέλνεται ειδοποίηση ολοκλήρωσης.
Μια εργασία που δεν υπάρχει προκαλεί συγκεκριμένο σφάλμα.
Η επανάληψη της ενέργειας δεν στέλνει δεύτερη ειδοποίηση.

Παρότι όλες μπορεί να σχετίζονται με μία μέθοδο, αξίζουν ξεχωριστά, εστιασμένα tests.

Ένα καλό test περιγράφει ποια απαίτηση ισχύει και υπό ποιες συνθήκες.

Η οικογένεια των test doubles

Το test double είναι ο γενικός όρος για ένα αντικείμενο που αντικαθιστά κάποιο άλλο κατά τη διάρκεια ενός test.

Δεν είναι όλα τα test doubles mocks.

Η παρακάτω ορολογία ακολουθεί τη διάκριση που παρουσιάζει ο Fowler, βασισμένος στο έργο του Gerard Meszaros. Mocks Aren’t Stubs

Είδος	Ρόλος	Απλό παράδειγμα
Dummy	Συμπληρώνει μια παράμετρο και δεν χρησιμοποιείται στο συγκεκριμένο test.	Ένα αντικείμενο που απαιτεί ο constructor, αλλά δεν καλείται.
Stub	Δίνει προκαθορισμένες απαντήσεις.	«Όταν ζητηθεί η εργασία, επέστρεψε αυτή την τιμή».
Fake	Παρέχει μια απλοποιημένη λειτουργική υλοποίηση.	Repository που αποθηκεύει αντικείμενα σε ένα dictionary.
Spy	Καταγράφει κλήσεις ώστε να τις εξετάσουμε.	Καταγραφέας των ειδοποιήσεων που ζητήθηκαν.
Mock	Χρησιμοποιείται για επαλήθευση προσδοκιών σχετικά με κλήσεις.	«Η ειδοποίηση πρέπει να κληθεί μία φορά με αυτό το ID».

Οι ονομασίες των βιβλιοθηκών δεν αντιστοιχούν πάντα ακριβώς σε αυτούς τους ρόλους.

Ένα αντικείμενο που δημιουργήθηκε από το unittest.mock μπορεί να χρησιμοποιείται μόνο ως stub. Αν απλώς επιστρέφει μια τιμή, κάνουμε stubbing. Αν επαληθεύουμε πώς κλήθηκε, κάνουμε interaction verification.

Αντίστοιχα, ένα χειροποίητο αντικείμενο που καταγράφει κλήσεις μπορεί να λειτουργεί ως spy.

Ο ρόλος μέσα στο test έχει περισσότερη σημασία από τον τρόπο δημιουργίας του αντικειμένου.

Η βασική διαφορά Fake και Mock

Ας υποθέσουμε ότι ολοκληρώνουμε μια εργασία.

Με fake repository μπορούμε να ελέγξουμε:

Μετά την εκτέλεση, το repository επιστρέφει την εργασία ως ολοκληρωμένη.

Με mock repository μπορούμε να ελέγξουμε:

Το use case κάλεσε τη μέθοδο αποθήκευσης με την ολοκληρωμένη εργασία.

Στην πρώτη περίπτωση εξετάζουμε την κατάσταση που προέκυψε, δηλαδή κάνουμε state verification. Στη δεύτερη εξετάζουμε μια αλληλεπίδραση, δηλαδή κάνουμε interaction verification.

Αυτά είναι διαφορετικά αποδεικτικά στοιχεία.

Το fake repository μάς επιτρέπει να αποθηκεύσουμε και μετά να διαβάσουμε δεδομένα. Το mock repository καταγράφει ότι ζητήθηκε μια αποθήκευση.

Κανένα από τα δύο, από μόνο του, δεν αποδεικνύει ότι λειτουργεί το πραγματικό SQL query.

Επίσης, οι άξονες δεν είναι απόλυτοι: ένα test μπορεί να χρησιμοποιεί fake και ταυτόχρονα να ελέγχει αλληλεπιδράσεις σε έναν δεύτερο συνεργάτη.

Το παράδειγμα που θα χρησιμοποιήσουμε

Θα υλοποιήσουμε το use case CompleteTask.

Οι απαιτήσεις του είναι:

Φορτώνει την εργασία.
Αν δεν υπάρχει, σηκώνει TaskNotFound.
Αν είναι ήδη ολοκληρωμένη, την επιστρέφει χωρίς νέα ειδοποίηση.
Διαφορετικά, την ολοκληρώνει και την αποθηκεύει.
Μετά την επιτυχημένη αποθήκευση, ζητά την αποστολή ειδοποίησης.

Για το repository ορίζουμε ένα μικρό συμβόλαιο:

Το get() επιστρέφει None όταν το ID δεν υπάρχει.
Το save() δημιουργεί ή αντικαθιστά την εργασία με το συγκεκριμένο ID.
Μια αποτυχία διαθεσιμότητας αποθήκευσης μπορεί να εκφραστεί ως RepositoryUnavailable.

Θα χρησιμοποιήσουμε δύο αρχεία:

tasks.py
test_tasks.py

Όλα τα blocks των tests που ακολουθούν μπαίνουν διαδοχικά στο ίδιο test_tasks.py.

Ο κώδικας της εφαρμογής

Στο tasks.py:

from dataclasses import dataclass, replace
from typing import Protocol


@dataclass(frozen=True)
class Task:
    id: str
    completed: bool = False

    def complete(self) -> "Task":
        return replace(self, completed=True)


class TaskNotFound(Exception):
    pass


class RepositoryUnavailable(Exception):
    pass


class TaskRepository(Protocol):
    def get(self, task_id: str) -> Task | None:
        ...

    def save(self, task: Task) -> None:
        ...


class CompletionNotifier(Protocol):
    def send(self, task_id: str) -> None:
        ...


class CompleteTask:
    def __init__(
        self,
        repository: TaskRepository,
        notifier: CompletionNotifier,
    ) -> None:
        self._repository = repository
        self._notifier = notifier

    def execute(self, task_id: str) -> Task:
        task = self._repository.get(task_id)

        if task is None:
            raise TaskNotFound(task_id)

        if task.completed:
            return task

        completed_task = task.complete()
        self._repository.save(completed_task)
        self._notifier.send(completed_task.id)
        return completed_task

Το Task εκφράζει την κατάσταση και τη μετάβαση ολοκλήρωσης.

Το CompleteTask συντονίζει τη φόρτωση, την αποθήκευση και την ειδοποίηση.

Τα TaskRepository και CompletionNotifier περιγράφουν τις δυνατότητες που χρειάζεται το use case. Δεν περιέχουν λεπτομέρειες SQL, HTTP ή κάποιου SDK.

Το Protocol επιτρέπει να περιγράψουμε αυτή τη δομή χωρίς να απαιτούμε κοινή βασική κλάση από κάθε υλοποίηση. Οι δηλώσεις τύπων δεν επιβάλλουν από μόνες τους το επιχειρησιακό συμβόλαιο κατά την εκτέλεση.

Πρώτα δοκιμάζουμε τον απλό κώδικα χωρίς doubles

Η ολοκλήρωση του ίδιου του Task δεν χρειάζεται repository ή υπηρεσία ειδοποιήσεων.

Στην αρχή του test_tasks.py βάζουμε τα imports:

import unittest
from collections.abc import Iterable
from unittest.mock import create_autospec
from tasks import (
    CompleteTask,
    CompletionNotifier,
    RepositoryUnavailable,
    Task,
    TaskNotFound,
    TaskRepository,
)

Και προσθέτουμε:

class TaskTest(unittest.TestCase):
    def test_task_can_be_completed_without_test_doubles(self):
        task = Task("task-1")

        result = task.complete()

        self.assertEqual(Task("task-1", completed=True), result)
        self.assertFalse(task.completed)

Το test ελέγχει την πραγματική υλοποίηση της συμπεριφοράς.

Ελέγχει επίσης ότι το αρχικό αντικείμενο παραμένει ανολοκλήρωτο: η μέθοδος επιστρέφει νέο αντικείμενο.

Δεν χρειάζεται να αντικαταστήσουμε με mock κάτι που είναι ήδη εύκολο να χρησιμοποιήσουμε.

Ο ίδιος έλεγχος με Fake

Για να ελέγξουμε το use case χωρίς πραγματική βάση, δημιουργούμε ένα repository που κρατά δεδομένα στη μνήμη.

Στο test_tasks.py:

class InMemoryTaskRepository:
    def __init__(self, tasks: Iterable[Task] = ()) -> None:
        self._tasks = {task.id: task for task in tasks}

    def get(self, task_id: str) -> Task | None:
        return self._tasks.get(task_id)

    def save(self, task: Task) -> None:
        self._tasks[task.id] = task

Αυτό είναι fake επειδή έχει λειτουργική συμπεριφορά:

Αποθηκεύει διαφορετικές εργασίες.
Αναζητά με βάση το ID.
Διατηρεί αλλαγές μεταξύ κλήσεων.
Αντικαθιστά υπάρχουσες εγγραφές.

Δεν χρειάζεται να ορίσουμε ξεχωριστά την απάντηση κάθε κλήσης.

Χρειαζόμαστε επίσης έναν απλό συνεργάτη για τις ειδοποιήσεις:

class RecordingNotifier:
    def __init__(self) -> None:
        self.sent_task_ids: list[str] = []

    def send(self, task_id: str) -> None:
        self.sent_task_ids.append(task_id)

Ο RecordingNotifier είναι spy: καταγράφει τις κλήσεις που δέχεται. Δεν υλοποιεί πραγματική παράδοση ειδοποιήσεων.

Το test με το fake repository είναι:

class CompleteTaskWithFakeTest(unittest.TestCase):
    def test_completed_task_is_persisted(self):
        # Arrange
        repository = InMemoryTaskRepository([Task("task-1")])
        notifier = RecordingNotifier()
        complete_task = CompleteTask(repository, notifier)

        # Act
        result = complete_task.execute("task-1")

        # Assert
        expected = Task("task-1", completed=True)
        self.assertEqual(expected, result)
        self.assertEqual(expected, repository.get("task-1"))

    def test_missing_task_raises(self):
        repository = InMemoryTaskRepository()
        notifier = RecordingNotifier()
        complete_task = CompleteTask(repository, notifier)

        with self.assertRaises(TaskNotFound):
            complete_task.execute("missing")

        self.assertEqual([], notifier.sent_task_ids)

Το πρώτο test περιγράφει μια ολοκληρωμένη ακολουθία:

Υπάρχει μια ανολοκλήρωτη εργασία. Την ολοκληρώνω. Διαβάζω την αποθηκευμένη κατάστασή της και είναι ολοκληρωμένη.

Δεν καθορίζει πόσες φορές επιτρέπεται να γίνει ανάγνωση από το repository.

Αν η υλοποίηση αλλάξει εσωτερικά, αλλά διατηρήσει το αποτέλεσμα και το συμβόλαιο, το test έχει περισσότερες πιθανότητες να παραμείνει χρήσιμο χωρίς αλλαγές.

Μια σημαντική παγίδα με mutable αντικείμενα

Το παράδειγμα χρησιμοποιεί Task με frozen=True και πεδία που είναι αμετάβλητες τιμές.

Αυτό αποτρέπει μια συνηθισμένη παγίδα των fake repositories.

Αν το repository επέστρεφε το ίδιο mutable αντικείμενο που κρατά εσωτερικά, ο κώδικας θα μπορούσε να κάνει:

task.completed = True

Η αλλαγή θα φαινόταν αμέσως μέσα στο fake, ακόμη και αν ξεχνούσαμε να καλέσουμε save().

Έτσι, ένα test θα μπορούσε να περνά ενώ η πραγματική αποθήκευση δεν θα λειτουργούσε.

Στο δικό μας παράδειγμα δημιουργείται νέο Task. Αν αφαιρέσουμε το save(), το fake συνεχίζει να περιέχει το παλιό αντικείμενο και το test αποτυγχάνει.

Η συμπεριφορά του fake πρέπει να σχεδιάζεται με προσοχή.

Ο ίδιος έλεγχος με Mock

Ας αντικαταστήσουμε τώρα το repository με ένα mock.

Στο test_tasks.py προσθέτουμε:

class CompleteTaskWithMockTest(unittest.TestCase):
    def test_completed_task_is_saved(self):
        # Arrange
        repository = create_autospec(
            TaskRepository, instance=True, spec_set=True
        )
        repository.get.return_value = Task("task-1")
        notifier = create_autospec(
            CompletionNotifier, instance=True, spec_set=True
        )
        complete_task = CompleteTask(repository, notifier)

        # Act
        result = complete_task.execute("task-1")

        # Assert
        expected = Task("task-1", completed=True)
        self.assertEqual(expected, result)
        repository.save.assert_called_once_with(expected)

    def test_missing_task_does_not_save_or_notify(self):
        repository = create_autospec(
            TaskRepository, instance=True, spec_set=True
        )
        repository.get.return_value = None
        notifier = create_autospec(
            CompletionNotifier, instance=True, spec_set=True
        )
        complete_task = CompleteTask(repository, notifier)

        with self.assertRaises(TaskNotFound):
            complete_task.execute("missing")

        repository.save.assert_not_called()
        notifier.send.assert_not_called()

    def test_failed_save_does_not_notify(self):
        repository = create_autospec(
            TaskRepository, instance=True, spec_set=True
        )
        repository.get.return_value = Task("task-1")
        repository.save.side_effect = RepositoryUnavailable()
        notifier = create_autospec(
            CompletionNotifier, instance=True, spec_set=True
        )
        complete_task = CompleteTask(repository, notifier)

        with self.assertRaises(RepositoryUnavailable):
            complete_task.execute("task-1")

        notifier.send.assert_not_called()

Εδώ η γραμμή:

repository.get.return_value = Task("task-1")

κάνει stubbing: ορίζει μια απάντηση.

Η γραμμή:

repository.save.assert_called_once_with(expected)

κάνει interaction verification: ελέγχει μια κλήση.

Το mock δεν αποθηκεύει την εργασία σε κάποιο λειτουργικό αποθετήριο. Καταγράφει ότι η save() κλήθηκε με το αναμενόμενο αντικείμενο.

Επίσης, το assert_called_once_with() προσθέτει την απαίτηση της μίας κλήσης. Αν το μόνο που ενδιαφέρει το προϊόν είναι η τελική κατάσταση, αυτό μπορεί να είναι αυστηρότερος περιορισμός από όσο χρειάζεται.

Αυτός είναι ένας λόγος να προτιμήσουμε το fake για τον συγκεκριμένο έλεγχο αποθήκευσης.

Γιατί χρησιμοποιούμε autospec και spec_set

Το create_autospec() δημιουργεί doubles με βάση το API που δίνουμε και ελέγχει τις υπογραφές των κλήσεων.

Το spec_set=True περιορίζει την πρόσβαση και την ανάθεση σε γνωστά attributes.

Έτσι, ένα λάθος όνομα μεθόδου ή λανθασμένος αριθμός παραμέτρων είναι πιθανότερο να αποκαλυφθεί άμεσα. Δεν επαληθεύονται, όμως, οι επιχειρησιακοί κανόνες ή οι τύποι επιστροφής από τα type hints. Τεκμηρίωση του unittest.mock

Το autospec μειώνει ορισμένα λάθη στη χρήση του API. Δεν αποδεικνύει ότι το double συμπεριφέρεται όπως ο πραγματικός adapter.

Πότε το mock είναι ιδιαίτερα βολικό

Το τρίτο test προκαλεί αποτυχία αποθήκευσης:

repository.save.side_effect = RepositoryUnavailable()

Και ελέγχει μια σαφή απαίτηση:

Αν η αποθήκευση αποτύχει, δεν πρέπει να ζητηθεί ειδοποίηση ολοκλήρωσης.

Δεν χρειάζεται να προσθέσουμε στο fake repository μηχανισμούς αποτυχίας για κάθε πιθανό σενάριο.

Για έναν μεμονωμένο έλεγχο σφάλματος, ένα μικρό stub ή ένα mock με side_effect μπορεί να είναι η πιο απλή λύση.

Fake και Mock στο ίδιο test

Δεν χρειάζεται να διαλέξουμε μία τεχνική για ολόκληρη την εφαρμογή.

Μπορούμε να χρησιμοποιήσουμε:

Fake repository για μια λειτουργική διαχείριση κατάστασης.
Mock notifier για να ελέγξουμε την απαίτηση αποστολής ειδοποίησης.

Προσθέτουμε στο test_tasks.py:

class CompleteTaskHybridTest(unittest.TestCase):
    def test_completion_sends_one_notification(self):
        repository = InMemoryTaskRepository([Task("task-1")])
        notifier = create_autospec(
            CompletionNotifier, instance=True, spec_set=True
        )
        complete_task = CompleteTask(repository, notifier)

        complete_task.execute("task-1")

        notifier.send.assert_called_once_with("task-1")

    def test_repeated_completion_does_not_notify_again(self):
        repository = InMemoryTaskRepository([Task("task-1")])
        notifier = create_autospec(
            CompletionNotifier, instance=True, spec_set=True
        )
        complete_task = CompleteTask(repository, notifier)

        complete_task.execute("task-1")
        complete_task.execute("task-1")

        notifier.send.assert_called_once_with("task-1")

Εδώ το mock ελέγχει κάτι που έχει άμεση επιχειρησιακή σημασία: να μη ζητηθεί δεύτερη ειδοποίηση για την ίδια ολοκλήρωση.

Το fake repository εξασφαλίζει ότι η δεύτερη εκτέλεση διαβάζει την κατάσταση που αποθήκευσε η πρώτη.

Δεν προγραμματίζουμε χειροκίνητα μια διαφορετική απάντηση για κάθε ανάγνωση. Η αλλαγή προκύπτει από τη λειτουργία του fake.

Το test αποδεικνύει τη συμπεριφορά για αυτές τις δύο διαδοχικές κλήσεις. Οι ταυτόχρονες κλήσεις είναι διαφορετικό σενάριο.

Τα Fakes χρειάζονται δικά τους tests

Ένα fake είναι επιπλέον κώδικας. Μπορεί να περιέχει bugs ή να αποκλίνει από την πραγματική υλοποίηση.

Χρειάζεται επομένως να ελέγχουμε το συμβόλαιό του.

Προσθέτουμε:

class InMemoryTaskRepositoryContractTest(unittest.TestCase):
    def setUp(self):
        self.repository = InMemoryTaskRepository()

    def test_unknown_id_returns_none(self):
        self.assertIsNone(self.repository.get("missing"))

    def test_saved_task_can_be_read(self):
        self.repository.save(Task("task-1"))

        self.assertEqual(Task("task-1"), self.repository.get("task-1"))

    def test_save_replaces_task_with_same_id(self):
        self.repository.save(Task("task-1"))

        self.repository.save(Task("task-1", completed=True))

        self.assertEqual(
            Task("task-1", completed=True),
            self.repository.get("task-1"),
        )

Αυτά ελέγχουν τρία σημεία του συμβολαίου μας:

Την απουσία εγγραφής.
Την ανάγνωση αποθηκευμένης εγγραφής.
Την αντικατάσταση εγγραφής με ίδιο ID.

Προς το παρόν εκτελούνται μόνο στο fake.

Όταν υπάρχει πραγματικός adapter, μπορούμε να οργανώσουμε αυτούς τους ίδιους ελέγχους ώστε να εκτελούνται και στις δύο υλοποιήσεις, με κατάλληλο setup και καθαρισμό.

Αυτή είναι η αξία των κοινών contract tests: ελέγχουν ότι οι υλοποιήσεις συμφωνούν στις συμπεριφορές που υπόσχεται το API. Δεν απαιτούν από το fake να αναπαράγει κάθε λεπτομέρεια της βάσης. Software Engineering at Google — Test Doubles

Για παράδειγμα, ένα dictionary δεν αποδεικνύει από μόνο του σωστή συμπεριφορά συναλλαγών, constraints ή ταυτόχρονων ενημερώσεων.

Αυτά χρειάζονται ελέγχους με την κατάλληλη πραγματική υποδομή.

Εκτέλεση των παραδειγμάτων

Αφού τοποθετήσουμε όλα τα προηγούμενα blocks στα δύο αρχεία, εκτελούμε από τον φάκελό τους:

python -m unittest -v

Η ολοκληρωμένη σουίτα περιλαμβάνει 11 tests.

Μπορούμε επίσης να δοκιμάσουμε μικρές σκόπιμες αλλαγές:

Αν αφαιρέσουμε το save(), αποτυγχάνουν τόσο το test αποθήκευσης με fake όσο και εκείνο με mock.
Αν αφαιρέσουμε το send(), αποτυγχάνει το test ειδοποίησης.
Αν αφαιρέσουμε τον έλεγχο task.completed, αποτυγχάνει το test της επανάληψης.

Αυτή είναι μια χρήσιμη ερώτηση για κάθε test:

Ποιο συγκεκριμένο λάθος στον κώδικα θα έκανε αυτό το test να αποτύχει;

Πότε προτιμάμε κάθε προσέγγιση

Ανάγκη	Συνήθως κατάλληλη επιλογή	Γιατί
Απλός υπολογισμός ή domain object	Πραγματική υλοποίηση	Έχει μικρό κόστος και ελέγχουμε τον πραγματικό κώδικα.
Αποθήκευση και ανάγνωση μέσα σε ένα σενάριο	Fake	Διατηρεί λειτουργική κατάσταση μεταξύ κλήσεων.
Πολλά tests χρειάζονται το ίδιο απλό repository	Κοινό fake	Μειώνει επαναλαμβανόμενο setup.
Μία συγκεκριμένη απάντηση από dependency	Stub	Εκφράζει απλά τη συνθήκη του σεναρίου.
Έλεγχος ότι ζητήθηκε ειδοποίηση	Mock ή spy	Η αλληλεπίδραση αποτελεί μέρος της απαίτησης.
Μεμονωμένη αποτυχία μιας εξάρτησης	Stub ή mock με σφάλμα	Το σενάριο ρυθμίζεται χωρίς πολύπλοκο fake.
SQL, mappings, constraints, συναλλαγές	Integration test	Χρειάζεται να εκτελεστεί ο πραγματικός adapter.
Ολόκληρη διαδρομή χρήστη	Επιλεγμένο end-to-end test	Ελέγχει τη σύνδεση των επιμέρους τμημάτων.

Ο πίνακας είναι πρακτικός οδηγός. Η τελική επιλογή εξαρτάται από το συμβόλαιο και το κόστος του test.

Ένα fake έχει αρχικό κόστος κατασκευής και συντήρησης. Συμφέρει περισσότερο όταν η απλή συμπεριφορά του επαναχρησιμοποιείται σε αρκετά σενάρια.

Ένα mock έχει μικρό αρχικό κόστος. Αν όμως κάθε test χρειάζεται μεγάλη λίστα ρυθμίσεων και επαληθεύσεων, το συνολικό κόστος συντήρησης αυξάνεται.

Η Google επισημαίνει ότι η υπερβολική χρήση mocks μπορεί να δυσκολεύει την κατανόηση και το refactoring, επειδή τα tests αρχίζουν να γνωρίζουν πολλές λεπτομέρειες της υλοποίησης. Don’t Overuse Mocks

Πώς συνδέεται αυτό με την Clean Architecture

Στην Clean Architecture οι εξαρτήσεις του πηγαίου κώδικα κατευθύνονται προς τις εσωτερικές πολιτικές και τους κανόνες της εφαρμογής.

Το use case δεν χρειάζεται να γνωρίζει αν η αποθήκευση γίνεται σε PostgreSQL, σε αρχείο ή μέσω κάποιου εξωτερικού API. Χρειάζεται ένα συμβόλαιο που εκφράζει τις δικές του ανάγκες. The Clean Architecture — Robert C. Martin

Μια πιθανή οργάνωση είναι:

domain/
    task.py

application/
    complete_task.py
    ports.py
    errors.py

infrastructure/
    postgres_task_repository.py
    email_completion_notifier.py

tests/
    unit/
    integration/

Στο άρθρο κρατήσαμε τον κώδικα σε δύο αρχεία για να είναι εύκολος στην εκτέλεση. Δεν χρειάζονται πολλοί φάκελοι για να καταλάβουμε την αρχή.

Οι εξαρτήσεις του πηγαίου κώδικα μπορούν να φαίνονται ως εξής:

CompleteTask ------------> TaskRepository
PostgresTaskRepository -> TaskRepository
InMemoryTaskRepository -> TaskRepository

Το CompleteTask χρησιμοποιεί το port.

Ο πραγματικός adapter και το fake υλοποιούν τη συμπεριφορά που περιγράφει το port. Στην Python αυτή η συμμόρφωση μπορεί να είναι δομική, χωρίς ρητή κληρονομικότητα.

Στην παραγωγή συνδέουμε το use case με τον πραγματικό adapter. Στα unit tests το συνδέουμε με το κατάλληλο double.

Αυτή η σύνδεση μέσω constructor είναι dependency injection. Δεν απαιτεί κάποιο ειδικό framework.

Η Clean Architecture διευκολύνει την επιλογή fake ή mock, επειδή κάνει τα όρια καθαρά. Δεν επιβάλλει μία από τις δύο τεχνικές.

Η σχέση με το SOLID

Το SOLID βοηθά να σχεδιάσουμε συνεργασίες που είναι κατανοητές και μπορούν να αντικατασταθούν με ελεγχόμενο τρόπο.

Single Responsibility Principle

Το Task διαχειρίζεται τη δική του μετάβαση κατάστασης.

Το CompleteTask συντονίζει το use case.

Ο adapter αποθήκευσης διαχειρίζεται την επικοινωνία με την υποδομή.

Αυτό περιορίζει την ανάμειξη διαφορετικών πηγών αλλαγής. Το SRP σχετίζεται με τους λόγους αλλαγής μιας μονάδας, όχι με έναν αυθαίρετο αριθμό μεθόδων ή γραμμών. The Single Responsibility Principle

Open Closed Principle

Μπορούμε να προσθέσουμε έναν adapter που στέλνει ειδοποιήσεις μέσω άλλης υπηρεσίας χωρίς να αλλάξουμε τη λογική ολοκλήρωσης.

Το σημείο σύνθεσης της εφαρμογής θα επιλέξει τη νέα υλοποίηση.

Αυτό δεν σημαίνει ότι πρέπει να προβλέψουμε κάθε μελλοντική αλλαγή. Χρειαζόμαστε χρήσιμα σημεία επέκτασης εκεί όπου υπάρχουν πραγματικά όρια. The Open Closed Principle

Liskov Substitution Principle

Ένα fake πρέπει να μπορεί να αντικαταστήσει τον πραγματικό συνεργάτη μέσα στο συμβόλαιο που ελέγχει.

Αν το πραγματικό repository επιστρέφει None όταν δεν βρίσκει εργασία, ενώ το fake επιστρέφει ένα κενό Task, οι υλοποιήσεις διαφωνούν σημασιολογικά.

Το ίδιο όνομα μεθόδου δεν αρκεί για ασφαλή υποκατάσταση.

Interface Segregation Principle

Το use case χρειάζεται ένα μικρό TaskRepository και έναν CompletionNotifier.

Δεν χρειάζεται ένα τεράστιο interface με διαχείριση χρηστών, migrations, exports και ειδοποιήσεις μαζί.

Ένα στενό συμβόλαιο περιορίζει και τις δυνατότητες που πρέπει να υλοποιήσει το fake.

Dependency Inversion Principle

Το use case εξαρτάται από τα ports που εκφράζουν τις ανάγκες της εφαρμογής.

Οι adapters προσαρμόζονται σε αυτά τα ports.

Η dependency injection είναι ένας τρόπος να συνδέσουμε τις υλοποιήσεις. Το Dependency Inversion αφορά τον σχεδιασμό και την κατεύθυνση των εξαρτήσεων. Design Principles and Design Patterns — Robert C. Martin

Best practices για καθαρά και χρήσιμα tests

Γράφουμε ένα test για μια συγκεκριμένη συμπεριφορά

Ένα test μπορεί να έχει περισσότερα από ένα assertions, όταν όλα τεκμηριώνουν την ίδια συμπεριφορά.

Στο test αποθήκευσης, η επιστρεφόμενη τιμή και η αποθηκευμένη κατάσταση περιγράφουν το ίδιο αποτέλεσμα.

Αν προσθέσουμε στο ίδιο test ειδοποιήσεις, permissions, audit logs και formatting, η αποτυχία γίνεται δυσκολότερο να ερμηνευτεί.

Η αντιστοιχία «μία μέθοδος παραγωγής, ένα test» δεν είναι χρήσιμος γενικός κανόνας. Test Behaviors, Not Methods

Κρατάμε καθαρά τα Arrange Act Assert

Το test πρέπει να επιτρέπει στον αναγνώστη να ξεχωρίζει:

Ποιες είναι οι αρχικές συνθήκες.
Ποια ενέργεια εκτελείται.
Ποιο αποτέλεσμα αναμένεται.

Δεν χρειάζεται κάθε test να έχει σχόλια Arrange, Act, Assert. Οι κενές γραμμές και τα σαφή ονόματα συχνά αρκούν.

Επαληθεύουμε μόνο τις αλληλεπιδράσεις που έχουν σημασία

Αν η απαίτηση είναι να σταλεί μία ειδοποίηση, έχει νόημα να ελέγξουμε τη μία κλήση.

Αν η απαίτηση είναι η τελική κατάσταση, μπορεί να μη χρειάζεται να ελέγξουμε πόσες φορές έγινε ανάγνωση από το repository.

Κάθε επαλήθευση κλήσης προσθέτει έναν περιορισμό.

Πριν τη γράψουμε, εξετάζουμε αν μια διαφορετική ακολουθία κλήσεων, με το ίδιο επιτρεπτό αποτέλεσμα, θα ήταν επίσης σωστή.

Δεν αντικαθιστούμε με mock τη συμπεριφορά που εξετάζουμε

Αν θέλουμε να ελέγξουμε το CompleteTask, εκτελούμε το πραγματικό CompleteTask.

Αν αντικαταστήσουμε τη δική του execute() με προκαθορισμένη απάντηση, δεν ελέγχουμε την υλοποίησή του.

Αντίστοιχα, αποφεύγουμε να κάνουμε mock απλά αντικείμενα δεδομένων όπως το Task. Ένα πραγματικό Task είναι εύκολο να δημιουργηθεί και δείχνει καθαρά το σενάριο.

Κάθε test ξεκινά με δική του κατάσταση

Στα παραδείγματα δημιουργούμε νέο repository και νέο notifier για κάθε test.

Έτσι αποφεύγουμε:

Δεδομένα που διαρρέουν μεταξύ tests.
Παλιές καταγραφές κλήσεων.
Εξάρτηση από τη σειρά εκτέλεσης.

Το γεγονός ότι ένα fake είναι γρήγορο δεν σημαίνει ότι πρέπει να μοιράζεται ως mutable global αντικείμενο.

Τα tests παραμένουν απλά

Προτιμάμε σαφείς τιμές εισόδου και σαφή αναμενόμενα αποτελέσματα.

Αποφεύγουμε να υπολογίζουμε το αναμενόμενο αποτέλεσμα αντιγράφοντας τον ίδιο αλγόριθμο με τον κώδικα παραγωγής. Θα μπορούσαμε να αντιγράψουμε και το ίδιο λάθος.

Επίσης, λίγη επανάληψη στο setup μπορεί να είναι προτιμότερη από ένα γενικό helper με πολλές παραμέτρους και κρυφές προεπιλογές. Don’t Put Logic in Tests

Δεν αφήνουμε το fake να γίνει δεύτερη βάση δεδομένων

Το fake υλοποιεί το απαραίτητο συμβόλαιο.

Αν αρχίσουμε να γράφουμε query planner, μηχανισμό συναλλαγών και περίπλοκη προσομοίωση locking, το κόστος του μπορεί να ξεπεράσει την αξία του.

Για συμπεριφορές που εξαρτώνται ουσιαστικά από τη συγκεκριμένη βάση, χρησιμοποιούμε την πραγματική τεχνολογία σε integration tests.

Κρατάμε τα εξωτερικά SDKs πίσω από χρήσιμα όρια

Αν το use case χρησιμοποιεί βαθιές αλυσίδες από αντικείμενα ενός SDK, τα tests μπορεί να χρειάζονται αντίστοιχες αλυσίδες mocks.

Ένα μικρό port, όπως το CompletionNotifier, μπορεί να περιορίσει αυτή τη γνώση στον adapter.

Ο adapter χρειάζεται δικούς του ελέγχους απέναντι στην πραγματική βιβλιοθήκη ή στο κατάλληλο περιβάλλον δοκιμών. Η σύσταση να αποφεύγουμε mocks για τύπους που δεν ελέγχουμε περιγράφεται και στο Google Testing Blog. Don’t Mock Types You Don’t Own

Ελέγχουμε τις αποτυχίες και τα όρια

Το happy path είναι μόνο ένα μέρος της συμπεριφοράς.

Στο παράδειγμά μας ελέγχουμε επίσης:

Απουσία εργασίας.
Αποτυχία αποθήκευσης.
Επανάληψη ολοκλήρωσης.

Σε άλλα use cases μπορεί να έχουν σημασία κενές είσοδοι, όρια ποσότητας, ληγμένες προθεσμίες ή ακυρωμένες ενέργειες.

Αν η συμπεριφορά εξαρτάται από χρόνο, τυχαιότητα ή δίκτυο, χρειαζόμαστε τρόπο να ελέγχουμε αυτές τις συνθήκες με προβλέψιμες εισόδους.

Χρησιμοποιούμε το coverage ως ένδειξη

Το coverage δείχνει ποιος κώδικας εκτελέστηκε. Δεν αποδεικνύει ότι τα assertions ελέγχουν σωστά τις απαιτήσεις.

Ένα test μπορεί να εκτελεί όλο το use case και να ελέγχει μόνο ότι η επιστρεφόμενη τιμή δεν είναι None.

Η δοκιμή με μικρά σκόπιμα λάθη, όπως η αφαίρεση της αποθήκευσης, βοηθά να αξιολογήσουμε αν το test προστατεύει πράγματι τη συμπεριφορά που δηλώνει.

Τι δεν αποδεικνύουν τα unit tests του παραδείγματος

Το fake και το mock μάς βοηθούν να ελέγξουμε τη λογική του use case.

Για την πραγματική εφαρμογή χρειάζονται επιπλέον αποδείξεις:

Επίπεδο	Τι θέλουμε να αποδείξουμε
Unit tests	Οι κανόνες και οι αποφάσεις του use case είναι σωστοί.
Κοινά contract tests	Fake και πραγματικός adapter συμφωνούν στο συμβόλαιο.
Integration tests	Ο adapter συνεργάζεται σωστά με βάση, SDK ή υπηρεσία.
Επιλεγμένα end-to-end tests	Μια κρίσιμη διαδρομή λειτουργεί μέσα στην εφαρμογή.

Υπάρχει επίσης ένα συγκεκριμένο όριο στον κώδικά μας.

Αποθηκεύουμε πρώτα την ολοκλήρωση και μετά ζητάμε ειδοποίηση. Αν η αποθήκευση πετύχει αλλά η ειδοποίηση αποτύχει, μια επόμενη εκτέλεση θα βρει ήδη ολοκληρωμένη την εργασία.

Η σημερινή υλοποίηση δεν εγγυάται αξιόπιστη παράδοση της ειδοποίησης σε αυτό το σενάριο. Ούτε ο διαδοχικός έλεγχος επανάληψης αποδεικνύει προστασία απέναντι σε ταυτόχρονες κλήσεις.

Αν απαιτείται αξιόπιστη σύνδεση αποθήκευσης και δημοσίευσης μηνύματος, μια επιλογή είναι το transactional outbox: αποθηκεύουμε την αλλαγή και την πρόθεση αποστολής στην ίδια συναλλαγή και επεξεργαζόμαστε την αποστολή ξεχωριστά. Χρειάζεται επίσης αντιμετώπιση πιθανών διπλών παραδόσεων. Transactional Outbox Pattern — AWS

Αυτό θα ήταν πρόσθετη απαίτηση της εφαρμογής, με δική της σχεδίαση και tests.

Πώς αποφασίζουμε στην πράξη

Πριν δημιουργήσουμε ένα test double, μπορούμε να ακολουθήσουμε αυτή τη σειρά σκέψης:

Ποια συμπεριφορά θέλω να αποδείξω; Διατυπώνω την απαίτηση πριν επιλέξω τεχνική.
Μπορώ να χρησιμοποιήσω την πραγματική υλοποίηση; Αν είναι απλή, γρήγορη και προβλέψιμη, τη χρησιμοποιώ.
Χρειάζομαι λειτουργική κατάσταση μεταξύ κλήσεων; Ένα μικρό fake συχνά βοηθά.
Χρειάζομαι μόνο μία συγκεκριμένη απάντηση ή αποτυχία; Ένα stub μπορεί να αρκεί.
Η κλήση προς έναν συνεργάτη είναι μέρος της απαίτησης; Χρησιμοποιώ mock ή spy και ελέγχω τις σχετικές λεπτομέρειες.
Η ορθότητα εξαρτάται από την πραγματική υποδομή; Προσθέτω integration test στο αντίστοιχο όριο.

Για το δικό μας παράδειγμα, το fake repository είναι μια καλή προεπιλογή για ελέγχους κατάστασης και επαναλαμβανόμενων ενεργειών. Το mock notifier είναι χρήσιμο όταν θέλουμε να επαληθεύσουμε την απαίτηση αποστολής. Ένα stub αποτυχίας διευκολύνει τον έλεγχο σφαλμάτων.

Ένα χρήσιμο test εκφράζει καθαρά την απαίτηση, εντοπίζει ουσιαστικά λάθη και επιτρέπει να αλλάζουμε την εσωτερική οργάνωση του κώδικα όσο διατηρούμε το συμφωνημένο συμβόλαιο.

Expression Mapping, Projection και Specification με ένα απλό παράδειγμα

nikosst — Fri, 16 Oct 2026 08:01:52 +0000

Όταν αναπτύσσουμε ένα API με EF Core, συνήθως ξεκινάμε από μια απλή ανάγκη, να διαβάσουμε κάποια δεδομένα και να τα επιστρέψουμε στον client. Γράφουμε το query, φορτώνουμε τα entities και τα μετατρέπουμε σε DTOs, ώστε η απάντηση να περιέχει τα πεδία που χρειάζεται η συγκεκριμένη λειτουργία.

Όταν χρειαζόμαστε πληροφορίες από σχετικές οντότητες, προσθέτουμε και ένα Include. Για παράδειγμα, μια λίστα παραγγελιών μπορεί να χρειάζεται το όνομα του πελάτη. Η φόρτωση της παραγγελίας μαζί με τον πελάτη φαίνεται μια φυσική επιλογή.

Σε αυτό το σημείο, όμως, υπάρχει μια λεπτομέρεια που εύκολα περνά απαρατήρητη, το ότι επιστρέφουμε ένα μικρό DTO δεν σημαίνει ότι διαβάσαμε και λίγα δεδομένα από τη βάση. Αν η μετατροπή γίνει αφού φορτωθούν τα entities, μπορεί να έχουμε ήδη μεταφέρει πεδία που η συγκεκριμένη απάντηση δεν χρησιμοποιεί.

Εδώ αποκτά αξία το projection, περιγράφουμε τη μορφή του αποτελέσματος μέσα στο ίδιο το query, ώστε το EF Core να γνωρίζει ποια δεδομένα χρειαζόμαστε πριν το εκτελέσει. Ένα mapping expression μάς επιτρέπει να κρατήσουμε αυτή την περιγραφή επαναχρησιμοποιήσιμη.

Με μια απλή λίστα παραγγελιών, θα δούμε πώς λειτουργεί αυτή η προσέγγιση, τι αλλάζει στο SQL και πώς συνδέεται με το Specification pattern. Θα εξετάσουμε επίσης πότε αξίζει να χρησιμοποιούμε αυτά τα εργαλεία, τι γίνεται όταν τα Include είναι πολλά και αν έχουν νόημα ακόμη και όταν τα entities μας είναι μικρά.

Ένα endpoint χρειάζεται να επιστρέψει τρία πεδία. Το query, όμως, φορτώνει δύο ολόκληρα entities, τα μετατρέπει σε DTOs και τελικά χρησιμοποιεί μόνο ένα μικρό μέρος των δεδομένων.

Ο κώδικας λειτουργεί. Η βάση και η εφαρμογή, όμως, κάνουν περισσότερη δουλειά από όση απαιτεί η συγκεκριμένη λειτουργία.

Ας δούμε πώς το projection αλλάζει αυτή τη συμπεριφορά, τι προσφέρει ένα mapping expression και πού συνδέεται το Specification pattern.

Το παράδειγμα θα είναι μια λίστα παραγγελιών

Έχουμε δύο entities:

Order: Id, Total, CustomerId, CreatedAt, InternalNotes.
Customer: Id, Name, Email, Phone.

Κάθε παραγγελία συνδέεται υποχρεωτικά με έναν πελάτη μέσω του navigation property Order.Customer.

Για τη λίστα μας χρειαζόμαστε μόνο:

public sealed record OrderSummaryDto(
    int Id,
    decimal Total,
    string CustomerName);

Μια συνηθισμένη υλοποίηση είναι η εξής:

decimal minimumTotal = 100m;

var orders = await db.Orders
    .AsNoTracking()
    .Include(o => o.Customer)
    .Where(o => o.Total >= minimumTotal)
    .ToListAsync();

var result = orders
    .Select(o => new OrderSummaryDto(
        o.Id,
        o.Total,
        o.Customer.Name))
    .ToList();

Στο ToListAsync() εκτελείται το query και δημιουργούνται τα Order και Customer objects στη μνήμη. Το mapping που ακολουθεί δουλεύει πάνω σε αυτά τα objects.

Το SQL έχει σχηματικά την παρακάτω μορφή:

SELECT
    o.Id,
    o.Total,
    o.CustomerId,
    o.CreatedAt,
    o.InternalNotes,
    c.Id,
    c.Name,
    c.Email,
    c.Phone
FROM Orders AS o
INNER JOIN Customers AS c ON o.CustomerId = c.Id
WHERE o.Total >= @minimumTotal;

Χρησιμοποιούμε τρία πεδία, αλλά παραλαμβάνουμε περισσότερα.

Μια απαραίτητη διευκρίνιση, το Include δεν φέρνει όλες τις εγγραφές των πινάκων. Το Where εξακολουθεί να περιορίζει τις παραγγελίες. Το Include ζητά να φορτωθούν και οι σχετικοί πελάτες ως entities, με τις χαρτογραφημένες scalar ιδιότητές τους.

Επίσης, δεν φορτώνει αυτόματα κάθε άλλη σχέση του Customer. Αφορά τη σχέση που ζητήσαμε να συμπεριληφθεί.

Τεκμηρίωση: Eager Loading

Projection: ορίζουμε το αποτέλεσμα μέσα στο query

Projection είναι η επιλογή και διαμόρφωση των δεδομένων που θα αποτελέσουν το αποτέλεσμα. Στο LINQ εκφράζεται με το Select.

Αντί να φορτώσουμε πλήρη entities και μετά να τα μετατρέψουμε, περιγράφουμε το DTO όσο το query παραμένει IQueryable:

var result = await db.Orders
    .Where(o => o.Total >= minimumTotal)
    .Select(o => new OrderSummaryDto(
        o.Id,
        o.Total,
        o.Customer.Name))
    .ToListAsync();

Το EF Core μπορεί πλέον να μεταφράσει το projection σε SQL που επιλέγει τις απαραίτητες στήλες:

SELECT
    o.Id,
    o.Total,
    c.Name AS CustomerName
FROM Orders AS o
INNER JOIN Customers AS c ON o.CustomerId = c.Id
WHERE o.Total >= @minimumTotal;

Το SQL είναι ενδεικτικό· η ακριβής μορφή εξαρτάται από τον provider και το μοντέλο.

Το JOIN παραμένει, επειδή χρειαζόμαστε το όνομα του πελάτη. Η διαφορά είναι ότι δεν μεταφέρουμε τα υπόλοιπα πεδία και δεν δημιουργούμε πλήρη Order και Customer entities.

Το DTO κατασκευάζεται στη .NET από τις τιμές που επιστρέφει το query.

Δεν χρειαζόμαστε Include για αυτό το projection. Η έκφραση o.Customer.Name περιγράφει ήδη ποια πληροφορία της σχέσης απαιτείται.

Ας το δούμε πιο αναλυτικά. Το Include έχει νόημα όταν ζητάμε από το EF να φορτώσει ολόκληρο το σχετικό entity, για παράδειγμα όταν θέλουμε να το τροποποιήσουμε και να καλέσουμε SaveChanges. Στο projection δεν ζητάμε entities, ζητάμε συγκεκριμένες τιμές. Το EF διαβάζει την έκφραση, καταλαβαίνει ότι χρειάζεται το Customer.Name, δημιουργεί το JOIN μόνο του και επιλέγει μόνο τις στήλες που χρησιμοποιούνται.

Αν προσθέσουμε Include μαζί με ένα Select που αλλάζει το σχήμα του αποτελέσματος, το EF Core το αγνοεί. Δεν προσφέρει τίποτα και προσθέτει μόνο θόρυβο στον κώδικα.

Σενάριο	Τι χρησιμοποιούμε
Queries που επιστρέφουν DTOs ή read μοντέλα	`Select`, χωρίς `Include`
Commands που τροποποιούν entities	`Include` μόνο για τις σχέσεις που χρειάζονται

Τεκμηρίωση: Project only properties you need

Τι είναι το mapping expression;

Αν το ίδιο projection χρησιμοποιείται σε περισσότερα σημεία, μπορούμε να το ορίσουμε μία φορά:

using System.Linq.Expressions;

public static class OrderMappings
{
    public static readonly Expression<Func<Order, OrderSummaryDto>>
        ToSummary = o => new OrderSummaryDto(
            o.Id,
            o.Total,
            o.Customer.Name);
}

Και να το χρησιμοποιήσουμε απευθείας στο query:

var query = db.Orders
    .Where(o => o.Total >= minimumTotal)
    .Select(OrderMappings.ToSummary);

var result = await query.ToListAsync();

Ο όρος expression mapper περιγράφει εδώ ένα mapping γραμμένο ως expression tree.

Η διάκριση έχει σημασία:

Το Func<Order, OrderSummaryDto> είναι ένας delegate που εκτελείται πάνω σε ένα object.
Το Expression<Func<Order, OrderSummaryDto>> αναπαριστά τον κώδικα ως δομή δεδομένων, την οποία το EF Core μπορεί να αναλύσει και να μεταφράσει σε SQL.

Δεν σημαίνει ότι κάθε C# έκφραση μεταφράζεται. Πρέπει να υποστηρίζεται από το EF Core και τον συγκεκριμένο provider.

Το ξεχωριστό expression δεν προσφέρει καλύτερο SQL από το ισοδύναμο inline Select. Προσφέρει επαναχρησιμοποίηση, αναγνωσιμότητα και κοινό σημείο συντήρησης.

Το όφελος στη μεταφορά δεδομένων προκύπτει επειδή το projection συμμετέχει στο query πριν από την εκτέλεσή του.

Τεκμηρίωση: Expression Trees

Τι γίνεται όταν τα Include είναι πολλά;

Ας υποθέσουμε ότι ένα query χρειάζεται δέκα Include. Το πρόβλημα δεν βρίσκεται στο mapping expression. Βρίσκεται στο SQL και στον όγκο των δεδομένων που μεταφέρονται:

Cartesian explosion. Όταν περισσότερα από ένα Include αφορούν collections (σχέσεις ένα-προς-πολλά), το JOIN πολλαπλασιάζει τις γραμμές. Με τρία collections των 100 στοιχείων η καθεμία, μία παραγγελία επιστρέφει 100 × 100 × 100 = 1.000.000 γραμμές. Τα πεδία του κύριου entity επαναλαμβάνονται σε κάθε γραμμή.
Πλατιά αποτελέσματα. Με δέκα JOIN, ακόμα και σε απλές σχέσεις many-to-one, κάθε γραμμή περιέχει τις στήλες έντεκα πινάκων. Αυξάνονται η κίνηση στο δίκτυο, η μνήμη και ο χρόνος δημιουργίας των objects.
Δυσκολότερο query plan. Πολλά JOIN δυσκολεύουν τον optimizer και την αξιοποίηση των indexes, και η απόδοση γίνεται λιγότερο προβλέψιμη όσο μεγαλώνουν τα δεδομένα.
Change tracking. Όλα τα entities παρακολουθούνται, κάτι που κοστίζει σε μνήμη και CPU. Στα reads αυτό αποφεύγεται με AsNoTracking().

Τι κάνουμε σε αυτή την περίπτωση:

Για reads, projection. Ζητάμε μόνο τις στήλες που χρειάζεται το DTO, ακόμα κι αν το μοντέλο έχει δέκα σχέσεις.
Όταν χρειάζονται entities και υπάρχουν πολλά collections, AsSplitQuery(). Το EF εκτελεί ξεχωριστό query για κάθε collection και αποφεύγεται το καρτεσιανό γινόμενο. Το αντίτιμο είναι περισσότερα round trips και πιθανή ασυνέπεια αν τα δεδομένα αλλάξουν ανάμεσα στα queries.
Όταν ένα DTO χρειάζεται πολλά collections, χωρίζουμε το αποτέλεσμα σε περισσότερα queries (π.χ. κύρια δεδομένα και ξεχωριστό query για τις γραμμές) και τα ενώνουμε στην εφαρμογή.

Προσοχή και στο projection με πολλά πεδία. Το EF μεταφράζει σε SQL ό,τι μπορεί, και η τελική κατασκευή του DTO γίνεται στη .NET. Δεν βάζουμε μέσα στο Select δικές μας μεθόδους ή πολύπλοκη λογική που δεν μεταφράζεται σε SQL, γιατί το EF είτε θα πετάξει exception είτε θα φέρει περισσότερα δεδομένα από όσα χρειάζεται. Κρατάμε το Select απλό και κάνουμε το υπόλοιπο mapping μετά το ToListAsync().

Τεκμηρίωση: Single vs. split queries

Πού μπαίνει το Specification;

Το Specification pattern οργανώνει κανόνες σε μια ονομασμένη, επαναχρησιμοποιήσιμη μονάδα.

Στην κλασική του μορφή περιγράφει ένα κριτήριο: για παράδειγμα, «παραγγελίες με ποσό μεγαλύτερο από ένα όριο».

Σε query-oriented υλοποιήσεις μπορεί να συγκεντρώνει επίσης ταξινόμηση, pagination, includes και projection.

Έννοια	Τι περιγράφει
Expression tree	Τον κώδικα σε μορφή που μπορεί να αναλυθεί και να μεταφραστεί.
Projection	Τη μορφή και τα πεδία του αποτελέσματος.
Query specification	Τους κανόνες ενός συγκεκριμένου query, ενδεχομένως μαζί με το projection.

Για παράδειγμα, με τη βιβλιοθήκη Ardalis.Specification:

using Ardalis.Specification;

public sealed class OrdersAboveTotalSpec
    : Specification<Order, OrderSummaryDto>
{
    public OrdersAboveTotalSpec(decimal minimumTotal)
    {
        Query
            .Where(o => o.Total >= minimumTotal)
            .Select(OrderMappings.ToSummary);
    }
}

Εδώ η specification συγκεντρώνει το κριτήριο αναζήτησης και χρησιμοποιεί το mapping expression για το αποτέλεσμα.

Τα δύο εργαλεία συνεργάζονται. Δεν χρειάζεται όμως να υιοθετήσουμε specifications για να χρησιμοποιήσουμε projection, ούτε κάθε specification πρέπει να επιστρέφει DTO.

Τεκμηρίωση: Select στο Ardalis.Specification

Έχει νόημα ακόμη και με μικρά entities;

Ναι. Δεν είναι κακή πρακτική να χρησιμοποιούμε expressions επειδή το entity έχει λίγα πεδία.

Για ένα read endpoint, το projection αποτυπώνει καθαρά τι χρειάζεται η συγκεκριμένη λειτουργία. Αν αργότερα προστεθούν πεδία στο entity, το συγκεκριμένο DTO projection συνεχίζει να ζητά τις ίδιες τιμές.

Το μετρήσιμο όφελος εξαρτάται από το μέγεθος των πεδίων, τον αριθμό των αποτελεσμάτων και τη συχνότητα εκτέλεσης. Σε ένα μικρό και σπάνιο query, η διαφορά μπορεί να είναι αμελητέα.

Η χρήσιμη διάκριση είναι:

Χρησιμοποιούμε Select για να διαμορφώσουμε ένα read result.
Εξάγουμε mapping expression όταν επαναχρησιμοποιείται ή κάνει τον κώδικα σαφέστερο.
Προσθέτουμε specification όταν οι κανόνες αναζήτησης χρειάζονται δική τους οργάνωση.

Δεν χρειάζεται ένα απλό query να αποκτήσει πολλές abstractions για να θεωρηθεί σωστό.

Οι λεπτομέρειες που κάνουν τη διαφορά

Το projection πρέπει να παραμένει μέσα στο IQueryable. Αν προηγηθεί ToList(), το query έχει ήδη εκτελεστεί. Αν περάσουμε σε AsEnumerable(), οι επόμενες LINQ πράξεις εκτελούνται στην εφαρμογή.

Αντίστοιχα, αποφεύγουμε αυτό:

db.Orders.Select(OrderMappings.ToSummary.Compile());

Το .Compile() μετατρέπει το expression σε delegate. Στη συγκεκριμένη κλήση επιλέγεται το Enumerable.Select, οπότε το mapping εκτελείται στη μνήμη.

Επίσης, μια custom μέθοδος μέσα σε expression δεν αποκτά αυτόματα SQL μετάφραση. Στο τελικό projection μπορεί να εκτελεστεί στην εφαρμογή, ενώ μια μη μεταφράσιμη συνθήκη στο Where συνήθως προκαλεί exception.

Τεκμηρίωση: Client vs. Server Evaluation

Το AsNoTracking() αφορά διαφορετικό θέμα: το change tracking. Δεν μειώνει τις επιλεγμένες στήλες. Στο δικό μας projection, που επιστρέφει μόνο τιμές μέσα σε DTO και κανένα entity instance, δεν υπάρχουν entities για tracking.

Τεκμηρίωση: Tracking and custom projections

Αν χρησιμοποιούμε AutoMapper, η αντίστοιχη δυνατότητα για query projection είναι το ProjectTo<TDto>(). Το mapper.Map πάνω σε ήδη φορτωμένα entities δεν μπορεί να αλλάξει τα δεδομένα που παραλάβαμε από τη βάση.

Τεκμηρίωση: AutoMapper Queryable Extensions

Για αναγνώσεις που επιστρέφουν DTOs, το projection είναι μια πρακτική προεπιλογή. Όταν χρειάζεται να φορτώσουμε entities για αλλαγές και εκτέλεση domain behavior, η φόρτωση του κατάλληλου entity graph εξακολουθεί να έχει θέση.

Και για να ελέγξουμε τι ζητά πραγματικά το query μας από τη βάση:

var sql = query.ToQueryString();

Η αξία της επιλογής φαίνεται στο παραγόμενο SQL και στις ανάγκες της λειτουργίας που υλοποιούμε.

Να θυμάσαι..!

Το Specification οργανώνει τα κριτήρια αναζήτησης, το Expression Mapping επιτρέπει τη μεταφορά εκφράσεων ανάμεσα σε διαφορετικά μοντέλα και το Projection καθορίζει τη μορφή των δεδομένων που επιστρέφουμε.

Συνδυάζοντάς τα, μπορούμε να χτίσουμε queries με σαφείς ευθύνες και λιγότερη επανάληψη, που προσαρμόζονται ευκολότερα στις αλλαγές της εφαρμογής. Η πραγματική τους αξία φαίνεται όταν προσθέτουμε ένα νέο φίλτρο ή αλλάζουμε ένα DTO και η υπάρχουσα δομή μάς βοηθά να κάνουμε την αλλαγή σε συγκεκριμένα σημεία. Αυτό είναι και το ζητούμενο, κώδικας που παραμένει κατανοητός και εύκολος στην εξέλιξη, όσο οι απαιτήσεις μεγαλώνουν.

Aggregates στο Domain-Driven Design: Πώς και γιατί τα χρησιμοποιούμε σε C# και .NET

nikosst — Mon, 12 Oct 2026 20:21:26 +0000

"Πλήρης οδηγός για Aggregates και Aggregate Roots στο DDD, με πρακτικά παραδείγματα C#, EF Core, Clean Architecture και Business Rules."
tags: dotnet, csharp, architecture, ddd

Όταν ξεκινάμε την ανάπτυξη μιας εφαρμογής με C# και ASP.NET Core, συνήθως σκεφτόμαστε με όρους Controllers, Services, Repositories, Entities και Database Tables.

Αυτή η προσέγγιση λειτουργεί αρκετά καλά σε απλές CRUD εφαρμογές.

Τι συμβαίνει όμως όταν η επιχειρησιακή λογική γίνεται πιο σύνθετη;

Τι γίνεται όταν μια παραγγελία δεν πρέπει να αλλάζει μετά την ολοκλήρωσή της; Όταν δεν επιτρέπεται να ολοκληρωθεί χωρίς προϊόντα; Ή όταν πολλές διαφορετικές λειτουργίες πρέπει να διατηρούν τα δεδομένα σε έγκυρη κατάσταση;

Εδώ έρχεται μία από τις σημαντικότερες έννοιες του Domain-Driven Design (DDD):

Το Aggregate.

Σε αυτό το άρθρο θα δούμε:

Τι είναι το Aggregate και το Aggregate Root.
Ποια προβλήματα λύνουν στην αρχιτεκτονική μιας εφαρμογής.
Πώς σχετίζονται με Entities και Value Objects.
Πώς υλοποιούμε ένα Aggregate με C#.
Πώς το συνδέουμε με Entity Framework Core.
Πώς εφαρμόζουμε Repository Pattern και Clean Architecture.
Πώς επιλέγουμε σωστά τα Aggregate Boundaries.
Ποια είναι τα συνηθέστερα λάθη.

Ας ξεκινήσουμε.

1. Τι είναι ένα Aggregate;

Στο Domain-Driven Design, ένα Aggregate είναι μια ομάδα από Domain Objects που αντιμετωπίζεται ως μία ενιαία μονάδα επιχειρησιακής συνέπειας.

Μπορεί να περιλαμβάνει:

Ένα Aggregate Root.
Άλλα Entities.
Value Objects.

Το σημαντικότερο χαρακτηριστικό του είναι ότι οι αλλαγές στην εσωτερική του κατάσταση ελέγχονται μέσω του Aggregate Root.

Παράδειγμα

Ας υποθέσουμε ότι αναπτύσσουμε ένα e-commerce σύστημα.

Μια παραγγελία περιλαμβάνει:

Order (Aggregate Root)
│
├── OrderItem (Entity)
│   ├── ProductId
│   ├── Quantity
│   └── UnitPrice
│
├── OrderItem (Entity)
│   ├── ProductId
│   ├── Quantity
│   └── UnitPrice
│
└── OrderStatus

Το Order είναι το Aggregate Root.

Αυτό σημαίνει ότι οι αλλαγές στα OrderItems πρέπει να πραγματοποιούνται μέσω του Order και όχι ανεξάρτητα.

Για παράδειγμα:

order.AddItem(productId, 2, 49.90m);

Αντί για:

orderItem.Quantity = 2;

Η διαφορά φαίνεται μικρή, αλλά έχει τεράστια αρχιτεκτονική σημασία.

Στην πρώτη περίπτωση, το Order ελέγχει αν επιτρέπεται η αλλαγή.

Στη δεύτερη, οποιοδήποτε σημείο της εφαρμογής μπορεί να τροποποιήσει το Entity χωρίς να εφαρμόσει τους επιχειρησιακούς κανόνες.

2. Γιατί χρειαζόμαστε Aggregates;

Ας δούμε ένα συνηθισμένο παράδειγμα από μια εφαρμογή που βασίζεται σε CRUD Services.

public async Task UpdateQuantity(
    Guid orderItemId,
    int quantity)
{
    var item = await dbContext.OrderItems
        .FindAsync(orderItemId);

    if (item is null)
        throw new Exception("Item not found");

    item.Quantity = quantity;

    await dbContext.SaveChangesAsync();
}

Αρχικά, ο κώδικας φαίνεται σωστός.

Αλλά υπάρχουν αρκετά προβλήματα.

Πρόβλημα 1: Δεν προστατεύονται οι Business Rules.

Τι γίνεται αν η παραγγελία έχει ήδη ολοκληρωθεί;

Πρόβλημα 2: Η επιχειρησιακή λογική βρίσκεται στο Application Service.

Αν χρειαστεί η ίδια λειτουργία από διαφορετικό σημείο της εφαρμογής, υπάρχει κίνδυνος να αντιγραφούν ή να παρακαμφθούν οι έλεγχοι.

Πρόβλημα 3: Το Domain Model είναι Anemic.

Τα Entities περιέχουν δεδομένα, αλλά όχι την επιχειρησιακή συμπεριφορά που τα αφορά.

Με το Aggregate, η ενέργεια μεταφέρεται στο Domain:

order.ChangeItemQuantity(productId, 5);

Το ίδιο το Order αναλαμβάνει να αποφασίσει αν επιτρέπεται η αλλαγή.

Αυτός είναι ο βασικός στόχος: να προστατεύουμε τους επιχειρησιακούς κανόνες μέσα στο Domain Model.

3. Aggregate Root vs Entity vs Value Object

Πριν προχωρήσουμε στην υλοποίηση, πρέπει να κατανοήσουμε τρεις βασικές έννοιες.

Entity

Ένα Entity είναι ένα αντικείμενο με μοναδική ταυτότητα.

Για παράδειγμα:

public class Customer
{
    public Guid Id { get; private set; }

    public string Name { get; private set; }
}

Δύο Customers με το ίδιο όνομα δεν είναι απαραίτητα ο ίδιος Customer.

Η ταυτότητά τους καθορίζεται από το Id.

Value Object

Ένα Value Object δεν έχει δική του επιχειρησιακή ταυτότητα.

Η ισότητά του καθορίζεται από τις τιμές του.

public sealed record Money(
    decimal Amount,
    string Currency);

Για παράδειγμα:

var first = new Money(100, "EUR");
var second = new Money(100, "EUR");

Console.WriteLine(first == second); // True

Σε production υλοποίηση θα προσθέταμε validation για το νόμισμα, το ποσό και τις επιτρεπόμενες πράξεις.

Aggregate Root

Το Aggregate Root είναι ένα Entity που αποτελεί το κεντρικό σημείο πρόσβασης σε ένα Aggregate.

Έχει την ευθύνη να προστατεύει τους κανόνες που πρέπει να ισχύουν σε όλη τη μονάδα συνέπειας.

Για παράδειγμα, ένα Order Aggregate μπορεί να επιβάλλει τους κανόνες:

Δεν επιτρέπονται προϊόντα με αρνητική ποσότητα.
Δεν επιτρέπονται αλλαγές σε ολοκληρωμένη παραγγελία.
Μια παραγγελία πρέπει να περιέχει τουλάχιστον ένα προϊόν για να ολοκληρωθεί.
Το συνολικό ποσό υπολογίζεται από τα OrderItems.

4. Υλοποιώντας το OrderItem Entity

Αρχικά, δημιουργούμε το OrderItem.

public sealed class OrderItem
{
    public Guid Id { get; private set; }

    public Guid ProductId { get; private set; }

    public int Quantity { get; private set; }

    public decimal UnitPrice { get; private set; }

    private OrderItem() { } // EF Core

    internal OrderItem(
        Guid productId,
        int quantity,
        decimal unitPrice)
    {
        if (productId == Guid.Empty)
            throw new ArgumentException(
                "Invalid product.");

        if (quantity <= 0)
            throw new ArgumentException(
                "Quantity must be positive.");

        if (unitPrice < 0)
            throw new ArgumentException(
                "Unit price cannot be negative.");

        Id = Guid.NewGuid();
        ProductId = productId;
        Quantity = quantity;
        UnitPrice = unitPrice;
    }

    internal void ChangeQuantity(int quantity)
    {
        if (quantity <= 0)
            throw new ArgumentException(
                "Quantity must be positive.");

        Quantity = quantity;
    }

    public decimal TotalPrice =>
        Quantity * UnitPrice;
}

Παρατηρούμε κάτι σημαντικό.

Το Quantity έχει private setter:

public int Quantity { get; private set; }

Επίσης, η μέθοδος αλλαγής ποσότητας δεν είναι public:

internal void ChangeQuantity(int quantity)

Αυτό περιορίζει τη δυνατότητα εξωτερικής τροποποίησης.

Η χρήση του internal αποτελεί έναν πρώτο περιορισμό πρόσβασης σε επίπεδο assembly. Δεν εξασφαλίζει από μόνη της ότι μόνο το Aggregate Root μπορεί να καλέσει τη μέθοδο.

Για αυστηρότερη προστασία μπορούμε να χρησιμοποιήσουμε επιπλέον encapsulation ή διαφορετική οργάνωση των Domain Types.

5. Υλοποιώντας το Order Aggregate Root

Ας δημιουργήσουμε πρώτα το OrderStatus.

public enum OrderStatus
{
    Draft = 0,
    Completed = 1,
    Cancelled = 2
}

Στη συνέχεια δημιουργούμε το Aggregate Root.

public sealed class Order
{
    private readonly List<OrderItem> _items = new();

    public Guid Id { get; private set; }

    public Guid CustomerId { get; private set; }

    public OrderStatus Status { get; private set; }

    public IReadOnlyCollection<OrderItem> Items =>
        _items.AsReadOnly();

    public decimal TotalAmount =>
        _items.Sum(x => x.TotalPrice);

    private Order() { } // EF Core

    public Order(Guid customerId)
    {
        if (customerId == Guid.Empty)
            throw new ArgumentException(
                "Invalid customer.");

        Id = Guid.NewGuid();
        CustomerId = customerId;
        Status = OrderStatus.Draft;
    }

    public void AddItem(
        Guid productId,
        int quantity,
        decimal unitPrice)
    {
        EnsureDraft();

        if (_items.Any(x => x.ProductId == productId))
            throw new InvalidOperationException(
                "Product already exists.");

        var item = new OrderItem(
            productId,
            quantity,
            unitPrice);

        _items.Add(item);
    }

    public void ChangeItemQuantity(
        Guid productId,
        int quantity)
    {
        EnsureDraft();

        var item = _items.SingleOrDefault(
            x => x.ProductId == productId);

        if (item is null)
            throw new InvalidOperationException(
                "Product not found.");

        item.ChangeQuantity(quantity);
    }

    public void RemoveItem(Guid productId)
    {
        EnsureDraft();

        var item = _items.SingleOrDefault(
            x => x.ProductId == productId);

        if (item is null)
            throw new InvalidOperationException(
                "Product not found.");

        _items.Remove(item);
    }

    public void Complete()
    {
        EnsureDraft();

        if (_items.Count == 0)
            throw new InvalidOperationException(
                "Cannot complete an empty order.");

        Status = OrderStatus.Completed;
    }

    public void Cancel()
    {
        EnsureDraft();

        Status = OrderStatus.Cancelled;
    }

    private void EnsureDraft()
    {
        if (Status != OrderStatus.Draft)
            throw new InvalidOperationException(
                "Order cannot be modified.");
    }
}

Τι κερδίσαμε;

Πλέον δεν μπορούμε να αλλάξουμε ανεξέλεγκτα την κατάσταση της παραγγελίας.

Όλες οι αλλαγές περνούν από συγκεκριμένες Domain Methods.

order.AddItem(productId, 2, 50m);

order.ChangeItemQuantity(productId, 3);

order.Complete();

Αν προσπαθήσουμε να αλλάξουμε την παραγγελία μετά την ολοκλήρωσή της:

order.AddItem(
    anotherProductId,
    1,
    20m);

Θα προκύψει exception.

Ο επιχειρησιακός κανόνας προστατεύεται ανεξάρτητα από το αν η ενέργεια ξεκίνησε από REST API, background job ή message consumer.

Αυτό είναι το πραγματικό πλεονέκτημα του Aggregate.

6. Aggregates και Entity Framework Core

Ένα Aggregate δεν είναι το ίδιο πράγμα με ένα Database Table.

Το Aggregate αποτελεί έννοια του Domain Model, ενώ το Entity Framework Core αναλαμβάνει το persistence.

Μπορούμε να χαρτογραφήσουμε το Order και τα OrderItems χρησιμοποιώντας Fluent API.

public sealed class AppDbContext : DbContext
{
    public AppDbContext(
        DbContextOptions<AppDbContext> options)
        : base(options)
    {
    }

    public DbSet<Order> Orders => Set<Order>();

    protected override void OnModelCreating(
        ModelBuilder modelBuilder)
    {
        modelBuilder.Entity<Order>(order =>
        {
            order.HasKey(x => x.Id);

            order.Property(x => x.Status)
                .HasConversion<int>();

            order.Ignore(x => x.TotalAmount);

            order.HasMany(x => x.Items)
                .WithOne()
                .HasForeignKey("OrderId")
                .OnDelete(DeleteBehavior.Cascade);

            order.Navigation(x => x.Items)
                .HasField("_items");

            order.Navigation(x => x.Items)
                .UsePropertyAccessMode(
                    PropertyAccessMode.Field);
        });

        modelBuilder.Entity<OrderItem>(item =>
        {
            item.HasKey(x => x.Id);

            item.Property(x => x.UnitPrice)
                .HasPrecision(18, 2);

            item.Ignore(x => x.TotalPrice);
        });
    }
}

Το OrderItem δεν χρειάζεται να εκτίθεται ως δημόσιο DbSet.

Έτσι εκφράζουμε την πρόθεσή μας να χειριζόμαστε το Order ως μία ενιαία επιχειρησιακή μονάδα.

Η φόρτωση του Aggregate μπορεί να γίνει ως εξής:

var order = await dbContext.Orders
    .Include(x => x.Items)
    .SingleAsync(x => x.Id == orderId);

Και στη συνέχεια:

order.AddItem(productId, 2, 49.90m);

await dbContext.SaveChangesAsync();

Το EF Core αναλαμβάνει το change tracking και το persistence.

Σημαντικό: Το mapping δεν επιβάλλει από μόνο του τους κανόνες πρόσβασης του DDD. Αυτοί πρέπει να προστατεύονται από το Domain API και την αρχιτεκτονική της εφαρμογής.

7. Repository Pattern και Aggregates

Στο Domain-Driven Design, τα Repositories συνήθως σχεδιάζονται γύρω από Aggregate Roots.

Για παράδειγμα:

public interface IOrderRepository
{
    Task<Order?> GetByIdAsync(
        Guid id,
        CancellationToken cancellationToken);

    Task AddAsync(
        Order order,
        CancellationToken cancellationToken);
}

Η υλοποίηση με EF Core:

public sealed class OrderRepository
    : IOrderRepository
{
    private readonly AppDbContext _context;

    public OrderRepository(AppDbContext context)
    {
        _context = context;
    }

    public Task<Order?> GetByIdAsync(
        Guid id,
        CancellationToken cancellationToken)
    {
        return _context.Orders
            .Include(x => x.Items)
            .SingleOrDefaultAsync(
                x => x.Id == id,
                cancellationToken);
    }

    public async Task AddAsync(
        Order order,
        CancellationToken cancellationToken)
    {
        await _context.Orders.AddAsync(
            order,
            cancellationToken);
    }
}

Δεν χρειάζεται να δημιουργήσουμε ξεχωριστό Repository για κάθε OrderItem.

Το OrderItem ανήκει στο Order Aggregate.

Επομένως, οι αλλαγές του γίνονται μέσω του Order.

Χρειαζόμαστε πάντα Repository Pattern;

Όχι απαραίτητα.

Το EF Core DbContext ήδη προσφέρει χαρακτηριστικά Repository και Unit of Work.

Ένα custom Repository είναι χρήσιμο όταν θέλουμε να απομονώσουμε το Domain/Application Layer από τις λεπτομέρειες του persistence ή να ορίσουμε συγκεκριμένες λειτουργίες ανάκτησης Aggregates.

Δεν πρέπει να προσθέτουμε abstractions χωρίς ουσιαστικό όφελος.

8. Aggregates μέσα στην Clean Architecture

Μια τυπική δομή έργου μπορεί να είναι:

src/
│
├── MyApp.Domain/
│   ├── Orders/
│   │   ├── Order.cs
│   │   ├── OrderItem.cs
│   │   └── OrderStatus.cs
│   │
│   └── Abstractions/
│       └── IOrderRepository.cs
│
├── MyApp.Application/
│   └── Orders/
│       └── CompleteOrder/
│           └── CompleteOrderHandler.cs
│
├── MyApp.Infrastructure/
│   ├── Persistence/
│   │   └── AppDbContext.cs
│   │
│   └── Repositories/
│       └── OrderRepository.cs
│
└── MyApp.Api/
    └── Controllers/
        └── OrdersController.cs

Το Domain δεν πρέπει να εξαρτάται από το Entity Framework Core ή από το ASP.NET Core.

Οι επιχειρησιακοί κανόνες πρέπει να μπορούν να εκτελεστούν και να ελεγχθούν ανεξάρτητα από τις τεχνολογίες υποδομής.

Application Handler

public sealed class CompleteOrderHandler
{
    private readonly IOrderRepository _repository;
    private readonly IUnitOfWork _unitOfWork;

    public CompleteOrderHandler(
        IOrderRepository repository,
        IUnitOfWork unitOfWork)
    {
        _repository = repository;
        _unitOfWork = unitOfWork;
    }

    public async Task Handle(
        Guid orderId,
        CancellationToken cancellationToken)
    {
        var order = await _repository.GetByIdAsync(
            orderId,
            cancellationToken);

        if (order is null)
            throw new KeyNotFoundException(
                "Order not found.");

        order.Complete();

        await _unitOfWork.SaveChangesAsync(
            cancellationToken);
    }
}

Εδώ το IUnitOfWork είναι ένα interface του Application ή Domain abstraction layer, με υλοποίηση στο Infrastructure.

Για παράδειγμα:

public interface IUnitOfWork
{
    Task<int> SaveChangesAsync(
        CancellationToken cancellationToken);
}

Ο Handler δεν περιέχει τον κανόνα που καθορίζει αν μια παραγγελία μπορεί να ολοκληρωθεί.

Απλώς καλεί:

order.Complete();

Η επιχειρησιακή απόφαση παραμένει στο Domain.

9. Aggregate = Consistency Boundary

Ένα από τα σημαντικότερα χαρακτηριστικά των Aggregates είναι ότι ορίζουν τα όρια της επιχειρησιακής συνέπειας.

Ας υποθέσουμε ότι έχουμε δύο Aggregates:

Order Aggregate
├── Order
└── OrderItems

Inventory Aggregate
├── InventoryItem
└── StockReservations

Το Order είναι υπεύθυνο για τους κανόνες της παραγγελίας.

Το Inventory είναι υπεύθυνο για τους κανόνες διαθεσιμότητας και δέσμευσης αποθέματος.

Δεν πρέπει να δημιουργήσουμε ένα τεράστιο Aggregate που περιλαμβάνει όλα τα παραπάνω μόνο και μόνο επειδή σχετίζονται μεταξύ τους.

Πώς επικοινωνούν διαφορετικά Aggregates;

Μέσω Application Services, Domain Events ή Integration Events, ανάλογα με τις απαιτήσεις.

Για παράδειγμα:

Order Completed
       |
       v
OrderCompleted Event
       |
       v
Inventory Reservation Workflow
       |
       v
Inventory Aggregate

Μια πιθανή υλοποίηση Domain Event:

public sealed record OrderCompletedDomainEvent(
    Guid OrderId,
    Guid CustomerId);

Το Aggregate μπορεί να καταγράφει το event κατά την ολοκλήρωση.

Ένας Application Handler μπορεί στη συνέχεια να συντονίζει την ενημέρωση του Inventory.

Σε distributed architectures, μπορούμε να χρησιμοποιήσουμε:

Transactional Outbox Pattern.
Idempotent Message Consumers.
Eventual Consistency.
Saga / Process Manager.

Δεν είναι όμως υποχρεωτικό κάθε επικοινωνία μεταξύ Aggregates να γίνεται ασύγχρονα.

Η επιλογή εξαρτάται από τις απαιτήσεις ατομικότητας, συνέπειας και διαθεσιμότητας.

10. Πώς αποφασίζουμε τα Aggregate Boundaries;

Αυτό είναι ίσως το σημαντικότερο και δυσκολότερο μέρος του σχεδιασμού.

Ένα συνηθισμένο λάθος είναι να θεωρούμε ότι κάθε σχέση μεταξύ Database Tables πρέπει να αντιστοιχεί σε ένα Aggregate.

Αυτό δεν ισχύει.

Τα Aggregate Boundaries καθορίζονται κυρίως από τους επιχειρησιακούς κανόνες και όχι από τα Foreign Keys.

Ερωτήσεις που πρέπει να κάνουμε

1. Ποιοι κανόνες πρέπει να ισχύουν άμεσα και ατομικά;

Αν μια αλλαγή πρέπει να διατηρεί συγκεκριμένα invariants σε πολλά Entities, αυτά ενδέχεται να ανήκουν στο ίδιο Aggregate.

2. Ποια αντικείμενα έχουν ανεξάρτητο lifecycle;

Αν ένα αντικείμενο μπορεί να δημιουργείται, να τροποποιείται και να διαγράφεται ανεξάρτητα, ίσως χρειάζεται δικό του Aggregate.

3. Πόσο μεγάλο γίνεται το Aggregate;

Ένα υπερβολικά μεγάλο Aggregate μπορεί να δημιουργήσει προβλήματα:

Concurrency conflicts.
Performance overhead.
Μεγάλα object graphs.
Δυσκολότερη συντήρηση.

4. Μπορούμε να χρησιμοποιήσουμε eventual consistency;

Αν δεν χρειάζεται άμεση συνέπεια μεταξύ δύο επιχειρησιακών λειτουργιών, ίσως είναι προτιμότερο να βρίσκονται σε διαφορετικά Aggregates.

Ένας πρακτικός κανόνας

Σχεδίασε το μικρότερο δυνατό Aggregate που μπορεί να προστατεύσει σωστά τα επιχειρησιακά invariants του.

11. Aggregates και Concurrency

Ακόμη και ένα σωστά σχεδιασμένο Aggregate μπορεί να αντιμετωπίσει προβλήματα όταν πολλοί χρήστες το τροποποιούν ταυτόχρονα.

Ας υποθέσουμε ότι δύο requests φορτώνουν την ίδια παραγγελία.

Request A                 Request B
    |                         |
Load Order               Load Order
    |                         |
Change Quantity          Complete Order
    |                         |
Save Changes             Save Changes

Χωρίς concurrency protection, μπορεί να προκύψουν χαμένες ενημερώσεις ή μη έγκυρη τελική κατάσταση.

Το Aggregate προστατεύει τους κανόνες στο επίπεδο του Domain Model, αλλά δεν αντικαθιστά τους μηχανισμούς concurrency του persistence layer.

Optimistic Concurrency με EF Core

Μπορούμε να χρησιμοποιήσουμε ένα concurrency token.

Για παράδειγμα, σε SQL Server:

public byte[] RowVersion { get; private set; }
    = Array.Empty<byte>();

Και στο mapping:

order.Property(x => x.RowVersion)
    .IsRowVersion();

Το EF Core μπορεί να εντοπίσει συγκρούσεις ενημέρωσης και να προκαλέσει DbUpdateConcurrencyException.

Για Aggregates με child entities χρειάζεται προσεκτικός σχεδιασμός ώστε οι αλλαγές των παιδιών να συμμετέχουν στην επιθυμητή στρατηγική concurrency. Ένα row version μόνο στον πίνακα του Root δεν προστατεύει αυτόματα όλες τις ενημερώσεις των child rows.

12. Unit Testing των Aggregates

Ένα από τα μεγαλύτερα πλεονεκτήματα του συγκεκριμένου σχεδιασμού είναι ότι μπορούμε να κάνουμε unit testing χωρίς database.

Με xUnit:

public sealed class OrderTests
{
    [Fact]
    public void Cannot_complete_empty_order()
    {
        var order = new Order(Guid.NewGuid());

        Assert.Throws<InvalidOperationException>(
            () => order.Complete());
    }

    [Fact]
    public void Cannot_modify_completed_order()
    {
        var order = new Order(Guid.NewGuid());

        order.AddItem(
            Guid.NewGuid(),
            2,
            50m);

        order.Complete();

        Assert.Throws<InvalidOperationException>(
            () => order.AddItem(
                Guid.NewGuid(),
                1,
                20m));
    }

    [Fact]
    public void Total_amount_is_calculated_correctly()
    {
        var order = new Order(Guid.NewGuid());

        order.AddItem(Guid.NewGuid(), 2, 50m);
        order.AddItem(Guid.NewGuid(), 1, 30m);

        Assert.Equal(130m, order.TotalAmount);
    }

    [Fact]
    public void Cannot_add_duplicate_product()
    {
        var order = new Order(Guid.NewGuid());
        var productId = Guid.NewGuid();

        order.AddItem(productId, 1, 20m);

        Assert.Throws<InvalidOperationException>(
            () => order.AddItem(productId, 2, 20m));
    }
}

Τα tests αυτά εκτελούνται χωρίς:

SQL Server.
Entity Framework Core.
HTTP Requests.
Dependency Injection.
Mock Repositories.

Ελέγχουμε απευθείας την επιχειρησιακή συμπεριφορά.

Αυτό κάνει το Domain Model πιο εύκολο να κατανοηθεί και να εξελιχθεί.

13. Συνηθισμένα λάθη στην εφαρμογή Aggregates

Λάθος 1: Public Setters παντού

public OrderStatus Status { get; set; }

Έτσι επιτρέπουμε σε οποιοδήποτε σημείο της εφαρμογής να αλλάξει την κατάσταση.

Προτιμούμε:

public OrderStatus Status { get; private set; }

public void Complete()
{
    // Validate business rules
}

Λάθος 2: Ένα Aggregate για ολόκληρο το Domain

Το Aggregate δεν είναι ένας μηχανισμός για να συνδέουμε όλα τα Entities μεταξύ τους.

Μεγάλα Aggregates αυξάνουν το κόστος φόρτωσης και τον κίνδυνο concurrency conflicts.

Λάθος 3: Business Logic στα Application Services

Το Application Layer πρέπει κυρίως να συντονίζει τη λειτουργία.

Δεν πρέπει να περιέχει κανόνες που ανήκουν στην εσωτερική συνέπεια του Aggregate.

Λάθος 4: Repository για κάθε Entity

Δεν χρειάζεται υποχρεωτικά:

OrderRepository
OrderItemRepository
OrderStatusRepository

Αν το OrderItem ανήκει στο Order Aggregate, η διαχείρισή του γίνεται μέσω του Order.

Λάθος 5: Σύγχυση Aggregate και Database Transaction

Ένα Aggregate ορίζει επιχειρησιακά όρια συνέπειας.

Δεν είναι απλώς ένα σύνολο εγγραφών που αποθηκεύονται μαζί.

Το database transaction είναι μηχανισμός υποδομής, ενώ το Aggregate είναι έννοια του Domain.

Λάθος 6: Χρήση Aggregates χωρίς πραγματικούς κανόνες

Δεν χρειάζεται κάθε Entity να αποκτήσει πολύπλοκο Aggregate Root.

Σε ένα απλό CRUD σύστημα, η επιπλέον πολυπλοκότητα μπορεί να μην προσφέρει ουσιαστικό όφελος.

14. Πότε πρέπει να χρησιμοποιούμε Aggregates;

Τα Aggregates είναι ιδιαίτερα χρήσιμα όταν αναπτύσσουμε εφαρμογές με σύνθετη επιχειρησιακή συμπεριφορά.

Για παράδειγμα:

E-commerce: Orders, Shopping Carts, Payments.

Banking: Accounts, Transfers, Loan Applications.

ERP: Invoices, Purchase Orders, Inventory Reservations.

Booking Systems: Reservations, Availability Allocations.

Insurance: Policies, Claims, Coverage Rules.

Σε αυτές τις περιπτώσεις, οι επιχειρησιακοί κανόνες είναι συχνά σημαντικότεροι από τις απλές CRUD λειτουργίες.

Το Aggregate μάς επιτρέπει να εκφράσουμε αυτούς τους κανόνες με σαφή και ελεγχόμενο τρόπο.

15. Τελικές σκέψεις

Το Aggregate είναι μία από τις πιο σημαντικές έννοιες του Domain-Driven Design.

Δεν είναι απλώς ένα design pattern για την οργάνωση Entities.

Είναι ένας τρόπος να σχεδιάζουμε το λογισμικό γύρω από την επιχειρησιακή συνέπεια και συμπεριφορά.

Όταν χρησιμοποιούμε σωστά Aggregates:

Οι Business Rules βρίσκονται στο Domain.
Τα Entities δεν τροποποιούνται ανεξέλεγκτα.
Τα Application Services γίνονται πιο απλά.
Τα Unit Tests εστιάζουν στην πραγματική επιχειρησιακή συμπεριφορά.
Τα όρια των transactions και της συνέπειας γίνονται πιο ξεκάθαρα.
Η εφαρμογή γίνεται ευκολότερη στη συντήρηση και στην εξέλιξη.

Το σημαντικότερο είναι να θυμόμαστε ότι δεν σχεδιάζουμε Aggregates με βάση τη δομή της βάσης δεδομένων, αλλά με βάση τους κανόνες του business.

An Aggregate is not just a collection of entities. It is a consistency boundary that protects business invariants.

Αυτή είναι η ουσία του Aggregate στο Domain-Driven Design.

dotnet #csharp #architecture #ddd

CQRS χωρίς MediatR στο .NET: Custom Implementation, Clean Architecture και Dependency Inversion

nikosst — Fri, 09 Oct 2026 19:32:49 +0000

Εισαγωγή

Το CQRS είναι μία από τις αρχιτεκτονικές προσεγγίσεις που συναντάμε συχνά σε εφαρμογές .NET οι οποίες χρειάζονται σαφή διαχωρισμό ευθυνών, ελεγχόμενη επιχειρησιακή λογική και δυνατότητα εξέλιξης χωρίς να αυξάνεται ανεξέλεγκτα η πολυπλοκότητα του κώδικα.

Στην πράξη, όμως, υπάρχει μια συνηθισμένη παρανόηση: πολλοί developers συνδέουν το CQRS με το MediatR σε τέτοιο βαθμό, ώστε θεωρούν ότι η χρήση της βιβλιοθήκης αποτελεί προϋπόθεση για την εφαρμογή του pattern.

Αυτό δεν ισχύει.

Το CQRS είναι αρχιτεκτονική προσέγγιση. Το MediatR είναι μία βιβλιοθήκη που μπορεί να χρησιμοποιηθεί για τη δρομολόγηση requests προς τους κατάλληλους handlers και για την εφαρμογή κοινών συμπεριφορών κατά την επεξεργασία τους.

Μπορούμε να εφαρμόσουμε CQRS χωρίς MediatR, χωρίς εξωτερική βιβλιοθήκη και χωρίς να εγκαταστήσουμε κάποιο framework που αναλαμβάνει μεγάλο μέρος της υποδομής. Το .NET διαθέτει ήδη Dependency Injection, generics και abstractions που μας επιτρέπουν να σχεδιάσουμε τη δική μας υλοποίηση.

Το ερώτημα, επομένως, δεν είναι αν μπορούμε να εφαρμόσουμε CQRS χωρίς MediatR. Μπορούμε.

Το πραγματικό ερώτημα είναι:

Ποια είναι η ελάχιστη custom υποδομή που χρειαζόμαστε ώστε η υλοποίηση να παραμένει καθαρή, επεκτάσιμη, ελέγξιμη και συνεπής με τις αρχές της Clean Architecture;

Σε αυτό το άρθρο θα σχεδιάσουμε μια ολοκληρωμένη προσέγγιση με C#, ASP.NET Core και Entity Framework Core, ξεκινώντας από τα βασικά contracts και φτάνοντας μέχρι το Dependency Injection και τα pipeline behaviors.

1. Τι ακριβώς προσφέρει το CQRS;

Το CQRS σημαίνει Command Query Responsibility Segregation.

Η βασική ιδέα είναι ότι διαχωρίζουμε τις ενέργειες που μεταβάλλουν την κατάσταση του συστήματος από εκείνες που διαβάζουν δεδομένα.

Ένα Command εκφράζει την πρόθεση να πραγματοποιηθεί μια ενέργεια. Για παράδειγμα:

CreateEmployeeCommand
UpdateEmployeeCommand
DeleteEmployeeCommand
AssignRoleCommand

Ένα Query εκφράζει την απαίτηση ανάκτησης δεδομένων:

GetEmployeeByIdQuery
GetEmployeesQuery
GetUserPermissionsQuery

Η διάκριση αυτή δεν είναι απλώς οργανωτική. Βοηθά να διαμορφώσουμε διαφορετικές συμβάσεις, διαφορετική λογική επεξεργασίας και διαφορετικές στρατηγικές πρόσβασης στα δεδομένα.

Ένα Command μπορεί να φορτώσει μια οντότητα, να ελέγξει τους επιχειρησιακούς κανόνες της και να αποθηκεύσει τις αλλαγές της. Ένα Query μπορεί να επιστρέψει απευθείας ένα DTO μέσω projection, χωρίς να χρειάζεται να φορτώσει ολόκληρο το Domain Model.

Σημαντικό: το CQRS δεν απαιτεί δύο διαφορετικές βάσεις δεδομένων. Μπορούμε να εφαρμόσουμε διαχωρισμό Commands και Queries χρησιμοποιώντας την ίδια SQL Server βάση και το ίδιο DbContext, όπου αυτό εξυπηρετεί τις ανάγκες της εφαρμογής.

Ούτε απαιτεί υποχρεωτικά Mediator, message broker, event sourcing ή microservices.

Αυτές είναι διαφορετικές σχεδιαστικές επιλογές.

2. CQRS και Mediator: δύο διαφορετικές έννοιες

Για να σχεδιάσουμε σωστά την υλοποίησή μας, πρέπει να διαχωρίσουμε τις ευθύνες τους.

Το CQRS ορίζει τον διαχωρισμό μεταξύ των ενεργειών ανάγνωσης και μεταβολής δεδομένων.

Το Mediator είναι ένα pattern επικοινωνίας. Επιτρέπει σε έναν caller να στέλνει ένα request χωρίς να χρειάζεται να γνωρίζει άμεσα τον συγκεκριμένο handler που θα το εκτελέσει.

Μια εφαρμογή μπορεί να έχει CQRS με MediatR, CQRS με custom dispatcher ή CQRS με απευθείας injection των handlers.

Και οι τρεις επιλογές είναι τεχνικά εφικτές. Δεν έχουν, όμως, τις ίδιες ιδιότητες.

Με άμεσο injection, ο caller γνωρίζει το interface του handler που χρειάζεται. Με έναν dispatcher, ο caller στέλνει ένα request και η υποδομή εντοπίζει τον κατάλληλο handler. Με έναν mediator, αποκτάμε συνήθως επιπλέον έτοιμες δυνατότητες για routing και pipeline behaviors.

Η επιλογή εξαρτάται από τις ανάγκες του συστήματος.

Για μια εφαρμογή με συγκεκριμένα, strongly typed endpoints, το άμεσο injection μπορεί να είναι επαρκές. Για ένα μεγαλύτερο σύστημα με πολλές κοινές συμπεριφορές, ίσως αξίζει να σχεδιάσουμε έναν dispatcher και ένα pipeline.

Δεν χρειάζεται να εισαγάγουμε περισσότερη έμμεση επικοινωνία από όση πραγματικά απαιτεί η εφαρμογή.

3. Η αρχιτεκτονική δομή της υλοποίησης

Ας υποθέσουμε ότι αναπτύσσουμε μια εφαρμογή διαχείρισης εργαζομένων, με SQL Server και Entity Framework Core.

Η δομή της λύσης μας θα μπορούσε να είναι η εξής:

src/
├── MyApplication.Domain/
│   ├── Entities/
│   │   └── Employee.cs
│   └── Exceptions/
│
├── MyApplication.Application/
│   ├── Abstractions/
│   │   ├── ICommand.cs
│   │   ├── IQuery.cs
│   │   ├── ICommandHandler.cs
│   │   └── IQueryHandler.cs
│   └── Employees/
│       ├── Commands/
│       │   └── CreateEmployee/
│       │       ├── CreateEmployeeCommand.cs
│       │       └── CreateEmployeeHandler.cs
│       └── Queries/
│           └── GetEmployeeById/
│               ├── GetEmployeeByIdQuery.cs
│               ├── EmployeeDto.cs
│               └── GetEmployeeByIdHandler.cs
│
├── MyApplication.Infrastructure/
│   ├── Persistence/
│   │   └── ApplicationDbContext.cs
│   └── DependencyInjection.cs
│
└── MyApplication.Api/
    ├── Controllers/
    │   └── EmployeesController.cs
    └── Program.cs

Η συγκεκριμένη δομή είναι ενδεικτική και όχι υποχρεωτική. Μπορούμε να οργανώσουμε το Application ανά feature, ώστε κάθε επιχειρησιακή λειτουργία να συγκεντρώνει τα σχετικά requests, handlers, validators και DTOs.

Η ουσία είναι τα όρια των εξαρτήσεων:

Το Domain περιέχει τις επιχειρησιακές οντότητες και τους κανόνες τους.
Το Application περιγράφει τις περιπτώσεις χρήσης και συντονίζει την εκτέλεσή τους.
Το Infrastructure υλοποιεί τις τεχνικές λεπτομέρειες, όπως η αποθήκευση δεδομένων.
Το API εκθέτει τις λειτουργίες προς τους εξωτερικούς clients.

Το CQRS δεν επιβάλλει από μόνο του αυτή τη δομή. Η Clean Architecture είναι εκείνη που μας βοηθά να ορίσουμε τα αρχιτεκτονικά όρια και τις κατευθύνσεις των εξαρτήσεων.

4. Πρώτο βήμα: Ορίζουμε τα contracts του CQRS

Το πρώτο πράγμα που χρειάζεται να αποφασίσουμε είναι ποια συμβόλαια θέλουμε να προσφέρει το Application layer.

Δεν ξεκινάμε γράφοντας dispatcher, reflection ή assembly scanning. Ξεκινάμε ορίζοντας τι σημαίνει Command, τι σημαίνει Query και τι περιμένουμε από τους αντίστοιχους handlers.

4.1 Command contracts

Στο ICommand.cs:

namespace MyApplication.Application.Abstractions;

public interface ICommand<TResult>
{
}

Το ICommand<TResult> είναι ένα marker interface. Δεν περιέχει μεθόδους. Δηλώνει ότι ένας συγκεκριμένος τύπος αντιπροσωπεύει ένα Command και προσδιορίζει τον τύπο του αποτελέσματος.

Για ενέργειες που δεν χρειάζονται επιστρεφόμενη τιμή, θα μπορούσαμε να ορίσουμε επιπλέον ένα ICommand χωρίς generic παράμετρο. Δεν είναι απαραίτητο, όμως, να υποστηρίζουμε και τις δύο περιπτώσεις από την πρώτη ημέρα.

4.2 Query contracts

Στο IQuery.cs:

namespace MyApplication.Application.Abstractions;

public interface IQuery<TResult>
{
}

Το Query διαθέτει επίσης έναν τύπο αποτελέσματος.

Για παράδειγμα, ένα Query μπορεί να επιστρέψει ένα DTO, μια συλλογή αποτελεσμάτων ή μια nullable τιμή όταν το ζητούμενο στοιχείο ενδέχεται να μην υπάρχει.

Η διαφορά από το Command δεν είναι ο τύπος επιστροφής. Είναι η σημασιολογία της λειτουργίας: ένα Query δεν πρέπει να μεταβάλλει την επιχειρησιακή κατάσταση του συστήματος.

Τα marker interfaces βοηθούν τον compiler και το Dependency Injection να αναγνωρίζουν τους τύπους που ανήκουν στην αντίστοιχη κατηγορία.

4.3 Command handler contract

Στο ICommandHandler.cs:

namespace MyApplication.Application.Abstractions;

public interface ICommandHandler<TCommand, TResult>
    where TCommand : ICommand<TResult>
{
    Task<TResult> HandleAsync(
        TCommand command,
        CancellationToken cancellationToken);
}

Αυτό το interface περιγράφει τη σύμβαση ενός Command Handler.

Το TCommand είναι ο τύπος της ενέργειας που θα εκτελεστεί και το TResult ο τύπος του αποτελέσματος.

Το CancellationToken είναι επίσης σημαντικό. Επιτρέπει στον caller να μεταφέρει το αίτημα ακύρωσης σε λειτουργίες όπως η πρόσβαση στη βάση δεδομένων.

Δεν θα πρέπει να το παραλείπουμε από την υποδομή μας απλώς επειδή υλοποιούμε custom CQRS.

4.4 Query handler contract

Στο IQueryHandler.cs:

namespace MyApplication.Application.Abstractions;

public interface IQueryHandler<TQuery, TResult>
    where TQuery : IQuery<TResult>
{
    Task<TResult> HandleAsync(
        TQuery query,
        CancellationToken cancellationToken);
}

Με αυτά τα τέσσερα contracts έχουμε ορίσει τον βασικό πυρήνα της υλοποίησης.

Δεν έχουμε ακόμη δημιουργήσει dispatcher. Δεν έχουμε γράψει reflection. Δεν έχουμε εγκαταστήσει εξωτερική βιβλιοθήκη.

Έχουμε απλώς ορίσει ένα ισχυρά τυποποιημένο συμβόλαιο για κάθε πλευρά του CQRS.

5. Υλοποίηση ενός πραγματικού Command

Ας δημιουργήσουμε τώρα μια λειτουργία καταχώρισης εργαζομένου.

Το Command θα βρίσκεται στο Application layer:

using MyApplication.Application.Abstractions;

namespace MyApplication.Application.Employees.Commands.CreateEmployee;

public sealed record CreateEmployeeCommand(
    string FirstName,
    string LastName,
    string Email) : ICommand<Guid>;

Το Command περιγράφει την πρόθεση του client. Δεν είναι η Domain Entity και δεν χρειάζεται να κληρονομεί από αυτήν.

Αυτή η διάκριση μάς επιτρέπει να διατηρούμε το API contract ανεξάρτητο από το εσωτερικό μοντέλο της εφαρμογής.

5.1 Η Domain Entity

Στο Domain layer:

namespace MyApplication.Domain.Entities;

public sealed class Employee
{
    public Guid Id { get; private set; }

    public string FirstName { get; private set; } = null!;

    public string LastName { get; private set; } = null!;

    public string Email { get; private set; } = null!;

    private Employee()
    {
        // Used by Entity Framework Core.
    }

    private Employee(
        Guid id,
        string firstName,
        string lastName,
        string email)
    {
        Id = id;
        FirstName = firstName;
        LastName = lastName;
        Email = email;
    }

    public static Employee Create(
        string firstName,
        string lastName,
        string email)
    {
        if (string.IsNullOrWhiteSpace(firstName))
            throw new ArgumentException(
                "First name is required.",
                nameof(firstName));

        if (string.IsNullOrWhiteSpace(lastName))
            throw new ArgumentException(
                "Last name is required.",
                nameof(lastName));

        if (string.IsNullOrWhiteSpace(email))
            throw new ArgumentException(
                "Email is required.",
                nameof(email));

        return new Employee(
            Guid.NewGuid(),
            firstName.Trim(),
            lastName.Trim(),
            email.Trim());
    }
}

Το παράδειγμα παρουσιάζει απλούς ελέγχους εισόδου. Σε πραγματική εφαρμογή, η πολιτική επικύρωσης email και οι κανόνες μοναδικότητας πρέπει να σχεδιαστούν ξεχωριστά, ενώ η μοναδικότητα στη βάση πρέπει να προστατεύεται με κατάλληλο unique constraint.

Το σημαντικό αρχιτεκτονικό σημείο είναι ότι η δημιουργία της οντότητας πραγματοποιείται μέσα από μια ελεγχόμενη λειτουργία και όχι μέσω ανεξέλεγκτης εξωτερικής τροποποίησης των ιδιοτήτων της.

Το Domain δεν γνωρίζει το CQRS, τον controller, το DbContext ή το Dependency Injection.

5.2 Η υλοποίηση του handler

Για να αποθηκεύσουμε την οντότητα, χρειαζόμαστε έναν τρόπο πρόσβασης στα δεδομένα. Ας υποθέσουμε ότι η εφαρμογή διαθέτει ένα IApplicationDbContext στο Application layer, το οποίο υλοποιείται από το Infrastructure με EF Core.

using Microsoft.EntityFrameworkCore;
using MyApplication.Application.Abstractions;
using MyApplication.Domain.Entities;

namespace MyApplication.Application.Employees.Commands.CreateEmployee;

public sealed class CreateEmployeeHandler
    : ICommandHandler<CreateEmployeeCommand, Guid>
{
    private readonly IApplicationDbContext _context;

    public CreateEmployeeHandler(
        IApplicationDbContext context)
    {
        _context = context;
    }

    public async Task<Guid> HandleAsync(
        CreateEmployeeCommand command,
        CancellationToken cancellationToken)
    {
        var employee = Employee.Create(
            command.FirstName,
            command.LastName,
            command.Email);

        _context.Employees.Add(employee);

        await _context.SaveChangesAsync(cancellationToken);

        return employee.Id;
    }
}

Το IApplicationDbContext είναι ένα ενδεικτικό abstraction που θα μπορούσε να οριστεί ως εξής:

using Microsoft.EntityFrameworkCore;
using MyApplication.Domain.Entities;

namespace MyApplication.Application.Abstractions;

public interface IApplicationDbContext
{
    DbSet<Employee> Employees { get; }

    Task<int> SaveChangesAsync(
        CancellationToken cancellationToken);
}

Το Infrastructure υλοποιεί αυτό το interface με ένα πραγματικό DbContext.

Έτσι, το Application εξαρτάται από το συμβόλαιο που χρειάζεται, όχι από τη συγκεκριμένη κλάση αποθήκευσης.

Αυτό είναι εφαρμογή του Dependency Inversion Principle. Δεν χρειάζεται να εισαγάγουμε Mediator για να πετύχουμε αυτή την ανεξαρτησία.

Σημειώνεται ότι ένα τέτοιο abstraction είναι επιλογή σχεδιασμού, όχι υποχρεωτικό βήμα. Σε ορισμένες εφαρμογές μπορεί να είναι καταλληλότερα repositories ή ένα διαφορετικό persistence contract. Το ζητούμενο είναι να αποφύγουμε την άσκοπη διαρροή υποδομών στο Domain και να επιλέξουμε τα abstractions βάσει πραγματικών αναγκών.

6. Υλοποίηση ενός Query

Η πλευρά των Queries έχει διαφορετικό στόχο: την ανάκτηση δεδομένων με όσο το δυνατόν πιο κατάλληλη διαδρομή για την εκάστοτε περίπτωση χρήσης.

Δημιουργούμε το Query:

using MyApplication.Application.Abstractions;

namespace MyApplication.Application.Employees.Queries.GetEmployeeById;

public sealed record GetEmployeeByIdQuery(Guid EmployeeId)
    : IQuery<EmployeeDto?>;

Και το DTO:

namespace MyApplication.Application.Employees.Queries.GetEmployeeById;

public sealed record EmployeeDto(
    Guid Id,
    string FirstName,
    string LastName,
    string Email);

Ο handler:

using Microsoft.EntityFrameworkCore;
using MyApplication.Application.Abstractions;

namespace MyApplication.Application.Employees.Queries.GetEmployeeById;

public sealed class GetEmployeeByIdHandler
    : IQueryHandler<GetEmployeeByIdQuery, EmployeeDto?>
{
    private readonly IApplicationDbContext _context;

    public GetEmployeeByIdHandler(
        IApplicationDbContext context)
    {
        _context = context;
    }

    public Task<EmployeeDto?> HandleAsync(
        GetEmployeeByIdQuery query,
        CancellationToken cancellationToken)
    {
        return _context.Employees
            .AsNoTracking()
            .Where(employee => employee.Id == query.EmployeeId)
            .Select(employee => new EmployeeDto(
                employee.Id,
                employee.FirstName,
                employee.LastName,
                employee.Email))
            .SingleOrDefaultAsync(cancellationToken);
    }
}

Η χρήση του AsNoTracking() είναι κατάλληλη εδώ, επειδή το Query δεν χρειάζεται να τροποποιήσει την οντότητα.

Η projection δημιουργεί το DTO μέσα στο query, ώστε η βάση να επιστρέψει μόνο τα πεδία που χρειαζόμαστε.

Δεν υπάρχει λόγος να φορτώσουμε ολόκληρο το Domain Model, εφόσον η συγκεκριμένη περίπτωση χρήσης χρειάζεται μόνο αυτά τα δεδομένα.

Αυτό είναι ένα από τα πρακτικά πλεονεκτήματα του διαχωρισμού Commands και Queries: μπορούμε να σχεδιάζουμε την ανάγνωση και τη μεταβολή δεδομένων με διαφορετικές προτεραιότητες, ακόμη και όταν χρησιμοποιούμε την ίδια βάση.

7. Χρειαζόμαστε υποχρεωτικά Dispatcher;

Όχι.

Αυτό είναι ένα από τα σημαντικότερα σημεία της υλοποίησης.

Εφόσον το API γνωρίζει ποιο handler χρειάζεται, μπορεί να κάνει inject απευθείας το αντίστοιχο interface.

Για παράδειγμα:

[ApiController]
[Route("api/employees")]
public sealed class EmployeesController : ControllerBase
{
    private readonly ICommandHandler<CreateEmployeeCommand, Guid>
        _createHandler;

    private readonly IQueryHandler<GetEmployeeByIdQuery, EmployeeDto?>
        _getHandler;

    public EmployeesController(
        ICommandHandler<CreateEmployeeCommand, Guid> createHandler,
        IQueryHandler<GetEmployeeByIdQuery, EmployeeDto?> getHandler)
    {
        _createHandler = createHandler;
        _getHandler = getHandler;
    }

    [HttpPost]
    public async Task<IActionResult> Create(
        CreateEmployeeCommand command,
        CancellationToken cancellationToken)
    {
        var id = await _createHandler.HandleAsync(
            command,
            cancellationToken);

        return CreatedAtAction(
            nameof(GetById),
            new { id },
            new { id });
    }

    [HttpGet("{id:guid}")]
    public async Task<IActionResult> GetById(
        Guid id,
        CancellationToken cancellationToken)
    {
        var result = await _getHandler.HandleAsync(
            new GetEmployeeByIdQuery(id),
            cancellationToken);

        if (result is null)
            return NotFound();

        return Ok(result);
    }
}

Ο controller εξαρτάται από abstractions, όχι από concrete handlers. Αυτό είναι σαφώς προτιμότερο από το να κάνει inject απευθείας το CreateEmployeeHandler, εφόσον θέλουμε να διατηρήσουμε ένα σταθερό συμβόλαιο μεταξύ Presentation και Application.

Ωστόσο, υπάρχει μια σχεδιαστική παρατήρηση: ο controller εξακολουθεί να γνωρίζει τα συγκεκριμένα request types και τα αντίστοιχα handler interfaces. Σε ένα API με λίγες λειτουργίες αυτό μπορεί να είναι απολύτως αποδεκτό.

Αν, αντίθετα, θέλουμε ένα ενιαίο σημείο εισόδου για όλα τα Commands και Queries, τότε μπορούμε να προσθέσουμε custom dispatchers.

Η απόφαση αυτή πρέπει να λαμβάνεται βάσει αναγκών, όχι επειδή το CQRS υποχρεώνει τη χρήση τους.

8. Custom Command Dispatcher και Query Dispatcher

Αν επιλέξουμε να υλοποιήσουμε έναν dispatcher, χρειαζόμαστε δύο ακόμη interfaces:

public interface ICommandDispatcher
{
    Task<TResult> SendAsync<TResult>(
        ICommand<TResult> command,
        CancellationToken cancellationToken);
}

public interface IQueryDispatcher
{
    Task<TResult> QueryAsync<TResult>(
        IQuery<TResult> query,
        CancellationToken cancellationToken);
}

Ο dispatcher θα αναλαμβάνει να βρει τον κατάλληλο handler και να του παραδώσει το request.

Εδώ, όμως, εμφανίζεται ένα τεχνικό ζήτημα: το IServiceProvider του .NET δεν γνωρίζει αυτόματα ποιος handler αντιστοιχεί σε ένα συγκεκριμένο request. Χρειάζεται να κατασκευάσουμε τον κατάλληλο κλειστό generic τύπο, όπως ICommandHandler<CreateEmployeeCommand, Guid>, και να τον επιλύσουμε από το DI container.

Μια πιθανή υλοποίηση είναι η εξής:

public sealed class CommandDispatcher : ICommandDispatcher
{
    private readonly IServiceProvider _serviceProvider;

    public CommandDispatcher(IServiceProvider serviceProvider)
    {
        _serviceProvider = serviceProvider;
    }

    public Task<TResult> SendAsync<TResult>(
        ICommand<TResult> command,
        CancellationToken cancellationToken)
    {
        var handlerType = typeof(ICommandHandler<,>)
            .MakeGenericType(command.GetType(), typeof(TResult));

        var handler = _serviceProvider.GetRequiredService(handlerType);

        var method = handlerType.GetMethod(nameof(
            ICommandHandler<ICommand<TResult>, TResult>.HandleAsync))!;

        return (Task<TResult>)method.Invoke(
            handler,
            new object[] { command, cancellationToken })!;
    }
}

Ο παραπάνω κώδικας δείχνει τη βασική ιδέα της δρομολόγησης, αλλά δεν θα τον θεωρούσα έτοιμη production υλοποίηση.

Η χρήση reflection εισάγει runtime αποτυχίες, δυσκολεύει την ανίχνευση σφαλμάτων κατά το compile time και απαιτεί ιδιαίτερη προσοχή στη διαχείριση των exceptions που προέρχονται από το MethodInfo.Invoke.

Σε ένα πραγματικό σύστημα θα εξέταζα μια πιο ισχυρά τυποποιημένη υλοποίηση, με προσεκτικά σχεδιασμένα adapters, ή θα επέλεγα απευθείας injection, εφόσον δεν υπήρχε πραγματική ανάγκη για dispatcher.

Αυτό είναι σημαντικό: δεν αξίζει να προσθέτουμε ένα custom abstraction εάν η υλοποίησή του δημιουργεί μεγαλύτερη πολυπλοκότητα από εκείνη που αφαιρεί.

Ο ίδιος προβληματισμός ισχύει για το Query Dispatcher. Αν δεν έχουμε ανάγκη για κοινό σημείο δρομολόγησης, δεν χρειάζεται να τον δημιουργήσουμε.

9. Dependency Injection: Πώς συνδέονται τα contracts με τους handlers;

Έχουμε ορίσει τα interfaces και τις υλοποιήσεις τους. Τώρα πρέπει να τις καταχωρίσουμε στο Dependency Injection container.

Η απλούστερη προσέγγιση είναι η χειροκίνητη καταχώριση:

builder.Services.AddScoped<
    ICommandHandler<CreateEmployeeCommand, Guid>,
    CreateEmployeeHandler>();

builder.Services.AddScoped<
    IQueryHandler<GetEmployeeByIdQuery, EmployeeDto?>,
    GetEmployeeByIdHandler>();

Αυτό είναι πλήρως έγκυρο και έχει ένα σημαντικό πλεονέκτημα: οι καταχωρίσεις είναι ρητές και εύκολα κατανοητές.

Το μειονέκτημα είναι ότι, όταν το Application layer περιλαμβάνει δεκάδες ή εκατοντάδες handlers, το Program.cs ή το αρχείο καταχωρίσεων μπορεί να γίνει δυσανάλογα μεγάλο.

Για αυτόν τον λόγο, σε μεγαλύτερα projects μπορούμε να δημιουργήσουμε μια επέκταση του IServiceCollection που συγκεντρώνει τις καταχωρίσεις.

Για παράδειγμα:

public static class DependencyInjection
{
    public static IServiceCollection AddApplication(
        this IServiceCollection services)
    {
        services.AddScoped<
            ICommandHandler<CreateEmployeeCommand, Guid>,
            CreateEmployeeHandler>();

        services.AddScoped<
            IQueryHandler<GetEmployeeByIdQuery, EmployeeDto?>,
            GetEmployeeByIdHandler>();

        return services;
    }
}

Και στο API:

builder.Services.AddApplication();

Αυτό δεν είναι αυτόματη ανακάλυψη handlers, αλλά είναι ήδη μια καθαρότερη οργάνωση των registrations.

Αν ο αριθμός των handlers αυξηθεί σημαντικά, μπορούμε να εξετάσουμε assembly scanning με reflection ή τη βιβλιοθήκη Scrutor.

Πρέπει, όμως, να θυμόμαστε ότι το assembly scanning είναι μηχανισμός καταχώρισης στο DI container. Δεν είναι απαραίτητο συστατικό του CQRS.

Επίσης, οι handlers που χρησιμοποιούν DbContext συνήθως πρέπει να έχουν scoped lifetime, συμβατό με το lifetime του context. Δεν θα πρέπει να καταχωρίζουμε τέτοιους handlers ως singletons.

10. Το πιο σημαντικό custom κομμάτι: Cross-cutting concerns

Μέχρι αυτό το σημείο, έχουμε υλοποιήσει το βασικό CQRS.

Στην πραγματικότητα, όμως, το δυσκολότερο ζήτημα σε ένα μεγαλύτερο project δεν είναι να δημιουργήσουμε handlers. Είναι να διαχειριστούμε τις συμπεριφορές που επαναλαμβάνονται σε πολλούς handlers.

Για παράδειγμα:

Validation
Logging
Authorization
Performance measurement
Audit logging
Transaction management
Idempotency, όπου απαιτείται

Αν κάθε handler πρέπει να υλοποιεί χειροκίνητα όλες αυτές τις λειτουργίες, θα δημιουργήσουμε duplication και θα δυσκολέψουμε τη συντήρηση.

Εδώ χρειαζόμαστε μια συνειδητή σχεδιαστική επιλογή.

Το MediatR προσφέρει pipeline behaviors. Χωρίς MediatR, μπορούμε να εφαρμόσουμε παρόμοιες ιδέες με decorators.

10.1 Παράδειγμα: Logging decorator

Ας υποθέσουμε ότι θέλουμε να καταγράφουμε την εκτέλεση Commands.

Μπορούμε να δημιουργήσουμε ένα decorator που υλοποιεί το ίδιο interface με τον πραγματικό handler και τον καλεί εσωτερικά:

public sealed class LoggingCommandHandler<TCommand, TResult>
    : ICommandHandler<TCommand, TResult>
    where TCommand : ICommand<TResult>
{
    private readonly ICommandHandler<TCommand, TResult> _inner;
    private readonly ILogger<LoggingCommandHandler<TCommand, TResult>>
        _logger;

    public LoggingCommandHandler(
        ICommandHandler<TCommand, TResult> inner,
        ILogger<LoggingCommandHandler<TCommand, TResult>> logger)
    {
        _inner = inner;
        _logger = logger;
    }

    public async Task<TResult> HandleAsync(
        TCommand command,
        CancellationToken cancellationToken)
    {
        var stopwatch = Stopwatch.StartNew();

        _logger.LogInformation(
            "Executing command {CommandType}",
            typeof(TCommand).Name);

        try
        {
            return await _inner.HandleAsync(
                command,
                cancellationToken);
        }
        finally
        {
            stopwatch.Stop();

            _logger.LogInformation(
                "Command {CommandType} completed in {ElapsedMs} ms",
                typeof(TCommand).Name,
                stopwatch.ElapsedMilliseconds);
        }
    }
}

Ο decorator δεν χρειάζεται να γνωρίζει τι σημαίνει επιχειρησιακά η δημιουργία ενός εργαζομένου. Δεν χρειάζεται να γνωρίζει το SQL schema ή τους κανόνες του Domain.

Αναλαμβάνει μόνο το logging της εκτέλεσης και στη συνέχεια μεταβιβάζει τον έλεγχο στον πραγματικό handler.

Αυτή είναι η ουσία του Decorator Pattern: επεκτείνουμε τη συμπεριφορά ενός component χωρίς να αλλάζουμε την επιχειρησιακή υλοποίησή του.

Σημειώνεται ότι το παραπάνω logging δεν καταγράφει το περιεχόμενο του Command. Αυτό είναι σκόπιμο, επειδή τα requests μπορεί να περιλαμβάνουν προσωπικά ή ευαίσθητα δεδομένα.

10.2 Πώς συνδέεται ο decorator με το DI;

Η ύπαρξη του decorator δεν σημαίνει ότι το DI container θα τον εφαρμόσει αυτόματα.

Χρειάζεται να οργανώσουμε τις καταχωρίσεις έτσι ώστε το interface να επιλύεται μέσω του decorator και όχι απευθείας μέσω του εσωτερικού handler.

Για λίγους handlers, μπορούμε να κάνουμε χειροκίνητη σύνθεση. Για παράδειγμα, θα μπορούσαμε να χρησιμοποιήσουμε ένα factory registration που δημιουργεί πρώτα τον πραγματικό handler και στη συνέχεια τον τυλίγει με τον logging decorator.

Σε μεγαλύτερο σύστημα, μια βιβλιοθήκη όπως το Scrutor μπορεί να διευκολύνει την εφαρμογή decorators σε καταχωρισμένες υπηρεσίες.

Πρέπει να προσέχουμε τη σειρά των decorators, καθώς και να διασφαλίζουμε ότι το factory δεν επιλύει ξανά το ίδιο interface με αποτέλεσμα κυκλική εξάρτηση.

Δεν αρκεί να γράψουμε μια κλάση LoggingCommandHandler. Πρέπει να διασφαλίσουμε ότι η πραγματική διαδρομή εκτέλεσης περνάει μέσα από αυτήν.

11. Validation χωρίς Mediator

Το validation είναι ένα άλλο χαρακτηριστικό που συχνά συνδέεται με το MediatR.

Δεν απαιτεί, όμως, Mediator.

Μπορούμε να χρησιμοποιήσουμε FluentValidation ή έναν δικό μας μηχανισμό επικύρωσης και να τον ενσωματώσουμε στη ροή εκτέλεσης.

Υπάρχουν δύο βασικές προσεγγίσεις.

Η πρώτη είναι να καλεί κάθε handler τον validator που χρειάζεται. Είναι απλή, αλλά μπορεί να δημιουργήσει επαναλαμβανόμενο κώδικα.

Η δεύτερη είναι να χρησιμοποιήσουμε έναν decorator ή μια κοινή pipeline abstraction που εκτελεί τους validators πριν καλέσει τον πραγματικό handler.

Η δεύτερη προσέγγιση είναι συνήθως πιο κατάλληλη όταν θέλουμε συνεπή συμπεριφορά σε μεγάλο αριθμό Commands.

Πρέπει, ωστόσο, να ξεχωρίζουμε το validation των εισερχόμενων δεδομένων από τους επιχειρησιακούς κανόνες.

Ένας validator μπορεί να ελέγξει αν ένα email έχει επιτρεπόμενη μορφή ή αν ένα απαιτούμενο πεδίο είναι κενό. Δεν πρέπει, όμως, να μεταφέρουμε κάθε επιχειρησιακό κανόνα σε ένα εξωτερικό validation layer.

Για παράδειγμα, η απαγόρευση μιας μετάβασης κατάστασης σε έναν εργαζόμενο μπορεί να αποτελεί κανόνα του Domain και να πρέπει να προστατεύεται από την ίδια την οντότητα, ανεξάρτητα από το ποιος καλεί τη λειτουργία.

Η αρχιτεκτονική μας πρέπει να διασφαλίζει ότι οι κανόνες δεν παρακάμπτονται όταν αλλάζει το API, προστίθεται background worker ή εισάγεται ένα νέο σημείο εισόδου.

12. Authorization: Πού πρέπει να εφαρμόζεται;

Το authorization χρειάζεται ακόμη μεγαλύτερη προσοχή, επειδή αφορά την ασφάλεια του συστήματος.

Μπορούμε να εφαρμόσουμε authorization στο ASP.NET Core API, μέσω policies και attributes, αλλά και σε επίπεδο Application όταν οι έλεγχοι εξαρτώνται από την επιχειρησιακή λειτουργία.

Για παράδειγμα, το API μπορεί να απαιτεί authenticated χρήστη, ενώ το Application layer μπορεί να πρέπει να ελέγξει αν ο συγκεκριμένος χρήστης έχει δικαίωμα να τροποποιήσει έναν συγκεκριμένο εργαζόμενο.

Ένας custom authorization decorator θα μπορούσε να εκτελεί έναν κοινό έλεγχο πριν από τον handler. Αυτό, όμως, απαιτεί προσεκτικό σχεδιασμό των contracts και της πληροφορίας που μεταφέρεται από το authenticated context.

Δεν θα έβαζα αυθαίρετα ολόκληρη τη λογική authorization μέσα σε έναν γενικό dispatcher. Ο dispatcher πρέπει να παραμένει υπεύθυνος για τη δρομολόγηση και όχι να μετατραπεί σε κεντρική κλάση που γνωρίζει κάθε επιχειρησιακό κανόνα.

Επίσης, το Domain δεν πρέπει να εξαρτάται από το ASP.NET Core HttpContext. Αν ένας επιχειρησιακός κανόνας χρειάζεται πληροφορία για τον τρέχοντα χρήστη, αυτή πρέπει να μεταφέρεται μέσα από ένα κατάλληλο abstraction, όπου αυτό είναι αναγκαίο.

Η επιλογή του μηχανισμού authorization εξαρτάται από το είδος του ελέγχου. Δεν είναι κάθε authorization rule κατάλληλο για ένα γενικό pipeline.

13. Transactions: Δεν τις αναλαμβάνει αυτόματα το CQRS

Ένα από τα πιο συνηθισμένα λάθη είναι να θεωρούμε ότι, επειδή έχουμε έναν handler ανά Command, έχουμε αυτόματα και σωστή διαχείριση transactions.

Δεν ισχύει.

Το CQRS δεν ορίζει πώς θα διαχειριστούμε τις συναλλαγές στη βάση δεδομένων.

Στο απλό παράδειγμά μας, το SaveChangesAsync() του EF Core αποθηκεύει τις αλλαγές και, για τις συνηθισμένες σχετικές λειτουργίες που εκτελούνται σε μία κλήση, το EF Core παρέχει transaction behavior όταν υποστηρίζεται από τον provider.

Αν όμως μια περίπτωση χρήσης περιλαμβάνει πολλές ξεχωριστές ενέργειες αποθήκευσης, πολλαπλά resources ή εξωτερικά συστήματα, πρέπει να σχεδιάσουμε συνειδητά τα όρια της συναλλαγής.

Δεν θα πρόσθετα transaction decorator μόνο και μόνο επειδή υπάρχει CQRS.

Θα τον πρόσθετα όταν το σύστημα έχει συγκεκριμένες ανάγκες διαχείρισης συναλλαγών που δεν καλύπτονται επαρκώς από το υπάρχον persistence layer.

Αν μια λειτουργία ενημερώνει τη βάση και στη συνέχεια στέλνει μήνυμα σε εξωτερικό broker, πρέπει επίσης να σκεφτούμε τι θα συμβεί αν η μία ενέργεια επιτύχει και η άλλη αποτύχει. Σε τέτοιες περιπτώσεις, τεχνικές όπως το transactional outbox μπορεί να είναι καταλληλότερες από την προσπάθεια να δημιουργήσουμε μια γενική transaction abstraction για κάθε πιθανή περίπτωση.

14. Πότε χρειάζεται custom dispatcher και πότε όχι;

Ας συνοψίσουμε τη σχεδιαστική απόφαση.

Επιλογή Α: Άμεσο injection των handlers

Ο controller εξαρτάται από το αντίστοιχο handler interface.

Πλεονεκτήματα:

Λιγότερος κώδικας υποδομής.
Strong typing σε compile time.
Εύκολη μετάβαση στον πραγματικό handler μέσω του debugger.
Δεν απαιτείται runtime routing.

Μειονεκτήματα:

Ο caller γνωρίζει τον τύπο του handler που χρειάζεται.
Δεν υπάρχει αυτόματα ενιαίο σημείο δρομολόγησης για όλα τα requests.
Η εφαρμογή κοινών behaviors χρειάζεται ξεχωριστό σχεδιασμό.

Επιλογή Β: Custom dispatcher

Ο caller στέλνει το Command ή το Query σε ένα κοινό abstraction.

Πλεονεκτήματα:

Ενιαίο σημείο εισόδου για την εκτέλεση requests.
Δυνατότητα κεντρικής σύνθεσης της ροής εκτέλεσης.
Μπορεί να είναι χρήσιμο σε generic infrastructure, background processing ή συστήματα που χρειάζονται runtime routing.

Μειονεκτήματα:

Περισσότερος κώδικας υποδομής.
Αν χρησιμοποιηθεί reflection, αυξάνεται η πολυπλοκότητα.
Χρειάζεται προσεκτικός σχεδιασμός του error handling, των registrations και των pipeline behaviors.

Για ένα τυπικό ASP.NET Core API, δεν θα θεωρούσα τον custom dispatcher υποχρεωτικό. Θα αξιολογούσα πρώτα αν η αφαίρεση που προσφέρει δικαιολογεί το κόστος της.

Αν η εφαρμογή χρειάζεται dispatcher, θα φρόντιζα να είναι όσο το δυνατόν πιο απλός, χωρίς επιχειρησιακή λογική και χωρίς να μετατρέπεται σε service locator για ολόκληρη την εφαρμογή.

15. Unit testing: Ένα από τα πραγματικά πλεονεκτήματα

Μια σωστά σχεδιασμένη υλοποίηση CQRS χωρίς Mediator μπορεί να είναι ιδιαίτερα εύκολη στη δοκιμή.

Ο handler είναι μια απλή κλάση με σαφείς εξαρτήσεις και μία συγκεκριμένη ευθύνη.

Για παράδειγμα, μπορούμε να γράψουμε ένα unit test για το CreateEmployeeHandler, ελέγχοντας ότι μια έγκυρη ενέργεια δημιουργεί και αποθηκεύει τον εργαζόμενο.

Το test μπορεί να χρησιμοποιήσει mock ή fake του persistence abstraction, ανάλογα με τη στρατηγική δοκιμών.

Παράλληλα, χρειάζονται integration tests για να επαληθεύσουμε ότι το EF Core, οι mappings, τα constraints και η πραγματική βάση λειτουργούν σωστά.

Δεν θα προσπαθούσα να αποδείξω τη σωστή λειτουργία της βάσης χρησιμοποιώντας αποκλειστικά mocks.

Επίσης, αν έχουμε custom dispatcher, χρειάζονται tests που να επιβεβαιώνουν ότι κάθε request επιλύεται στον σωστό handler και ότι τα pipeline behaviors εκτελούνται με τη σωστή σειρά.

Η απουσία MediatR δεν μειώνει από μόνη της την testability. Αυτή εξαρτάται κυρίως από τον σχεδιασμό των εξαρτήσεων και των συμβολαίων.

16. Συνηθισμένα αρχιτεκτονικά λάθη

Λάθος 1: Θεωρούμε ότι CQRS σημαίνει δύο βάσεις δεδομένων

Ο διαχωρισμός Commands και Queries μπορεί να υλοποιηθεί με μία κοινή βάση. Διαφορετικά read models ή ξεχωριστές βάσεις αποτελούν πρόσθετες επιλογές.

Λάθος 2: Τοποθετούμε όλη την επιχειρησιακή λογική στους handlers

Ο handler πρέπει κυρίως να συντονίζει τη συγκεκριμένη περίπτωση χρήσης. Οι ουσιαστικοί επιχειρησιακοί κανόνες πρέπει να βρίσκονται στο κατάλληλο Domain Model ή σε κατάλληλες domain services.

Λάθος 3: Δημιουργούμε dispatcher χωρίς πραγματική ανάγκη

Αν ο caller γνωρίζει ήδη τον handler που χρειάζεται, το άμεσο injection μπορεί να είναι απλούστερο και επαρκές.

Λάθος 4: Γράφουμε custom Mediator και τελικά ανακατασκευάζουμε ολόκληρο framework

Ένας dispatcher, ένας μηχανισμός reflection, ένα σύστημα registration, decorators, validation pipelines, event publishing και transaction management μπορούν να εξελιχθούν σε σημαντική υποδομή.

Αυτό δεν είναι απαραίτητα λάθος, αλλά πρέπει να δικαιολογείται από τις απαιτήσεις του συστήματος. Δεν χρειάζεται να υλοποιούμε κάθε πιθανή δυνατότητα πριν υπάρξει πραγματική ανάγκη.

Λάθος 5: Θεωρούμε ότι η απουσία MediatR εξασφαλίζει καλύτερη αρχιτεκτονική

Η ποιότητα της αρχιτεκτονικής δεν καθορίζεται από το αν χρησιμοποιούμε εξωτερική βιβλιοθήκη.

Καθορίζεται από τα όρια των εξαρτήσεων, τη σαφήνεια των contracts, τη διαχείριση των επιχειρησιακών κανόνων και τη δυνατότητα εξέλιξης του συστήματος.

17. Τι θα επέλεγα σε ένα πραγματικό production project;

Για μια εφαρμογή που ακολουθεί Clean Architecture και έχει σαφή διαχωρισμό Commands και Queries, θα ξεκινούσα από μια μικρή, ρητή υλοποίηση.

Θα δημιουργούσα τα contracts ICommand<TResult>, IQuery<TResult>, ICommandHandler<TCommand, TResult> και IQueryHandler<TQuery, TResult>.

Θα διατηρούσα κάθε handler υπεύθυνο για μία συγκεκριμένη περίπτωση χρήσης και θα χρησιμοποιούσα Dependency Injection για να συνδέσω τις υλοποιήσεις με τα interfaces τους.

Θα επέλεγα απευθείας injection όταν αυτό επαρκεί. Θα πρόσθετα custom dispatcher μόνο εφόσον υπήρχε σαφής ανάγκη για ενιαίο routing.

Για τα cross-cutting concerns θα εξέταζα decorators, validation abstractions και κατάλληλες υπηρεσίες του ASP.NET Core. Δεν θα συγκέντρωνα όλες τις ευθύνες σε έναν κεντρικό dispatcher.

Τέλος, θα διασφάλιζα ότι οι handlers παραμένουν testable, ότι τα transactions έχουν σαφή όρια και ότι το Domain δεν εξαρτάται από τεχνικές λεπτομέρειες του Infrastructure.

Η προσέγγιση αυτή δεν είναι η μοναδική σωστή λύση. Είναι, όμως, μια συνειδητή αρχιτεκτονική επιλογή που μπορεί να προσφέρει έλεγχο και σαφήνεια χωρίς να εισάγει εξαρτήσεις ή πολυπλοκότητα χωρίς συγκεκριμένο όφελος.

Συμπέρασμα

Το CQRS δεν είναι συνώνυμο του MediatR. Είναι μια προσέγγιση που διαχωρίζει τις λειτουργίες ανάγνωσης από τις λειτουργίες μεταβολής της κατάστασης του συστήματος.

Μπορούμε να το υλοποιήσουμε με custom interfaces, handlers και το ενσωματωμένο Dependency Injection του .NET. Μπορούμε επίσης να προσθέσουμε dispatcher και pipeline behaviors όταν οι απαιτήσεις της εφαρμογής το δικαιολογούν.

Το κρίσιμο σημείο είναι να γνωρίζουμε τι προσφέρει κάθε abstraction και ποιο πρόβλημα λύνει.

Δεν χρειάζεται να δημιουργήσουμε έναν custom Mediator μόνο και μόνο για να πούμε ότι έχουμε CQRS. Χρειάζεται να σχεδιάσουμε σωστά τις εξαρτήσεις, να διαχωρίσουμε τις ευθύνες και να διασφαλίσουμε ότι το σύστημα παραμένει εύκολο στη συντήρηση και στην επέκταση.

Η αρχιτεκτονική ποιότητα δεν προκύπτει από τον αριθμό των abstractions ή των βιβλιοθηκών που χρησιμοποιούμε. Προκύπτει από το αν οι σχεδιαστικές επιλογές μας λύνουν πραγματικά προβλήματα, διατηρώντας τον κώδικα κατανοητό και ελεγχόμενο.

Πηγές και περαιτέρω μελέτη

Microsoft Learn — Implementing the microservice application layer using the Web API

Εξηγεί την υλοποίηση Commands και Handlers, τη χρήση του Dependency Injection και τον ρόλο του Mediator και των pipeline behaviors.

Microsoft Learn — Designing a DDD-oriented microservice

Αναλύει τον διαχωρισμό Domain, Application και Infrastructure και τον ρόλο της επιχειρησιακής λογικής στο Domain Model.

Adrián Bailador — CQRS Without MediatR: Hand-Rolled Command and Query Handlers in .NET

Παρουσιάζει μια εναλλακτική προσέγγιση με custom contracts, dispatchers και pipeline behaviors.

GitHub — CQRS Without MediatR: Sample implementation

Παράδειγμα υλοποίησης σε .NET με custom handlers, Dependency Injection και decorators.

Repository Pattern στο .NET: Είναι πραγματικά ξεπερασμένο επειδή το Entity Framework Core το υλοποιεί ήδη;

nikosst — Fri, 09 Oct 2026 19:09:25 +0000

Υπότιτλος: Clean Architecture, Dependency Inversion, αρχιτεκτονικά όρια και οι πραγματικοί συμβιβασμοί πίσω από τα custom repositories.

Εισαγωγή

Κάθε τόσο επανέρχεται στις κοινότητες των .NET developers η ίδια συζήτηση:

«Γιατί χρησιμοποιείς Repository Pattern; Το Entity Framework Core υλοποιεί ήδη Repository και Unit of Work. Η επιπλέον αφαίρεση είναι περιττή και ξεπερασμένη».

Με την πρώτη ματιά, το επιχείρημα ακούγεται λογικό. Το Entity Framework Core παρέχει το DbSet<T> για την εργασία με οντότητες και το DbContext για την παρακολούθηση αλλαγών και την αποθήκευσή τους. Γιατί, λοιπόν, να προσθέσουμε επιπλέον interfaces και κλάσεις που φαίνεται να κάνουν ακριβώς το ίδιο πράγμα;

Ωστόσο, αυτή η συζήτηση συχνά συγχέει δύο διαφορετικά ερωτήματα:

Παρέχει το Entity Framework Core λειτουργίες αντίστοιχες με Repository και Unit of Work;
Σημαίνει αυτό ότι ένα custom Repository δεν έχει αρχιτεκτονική αξία;

Στο πρώτο ερώτημα η απάντηση είναι ναι. Στο δεύτερο, όχι.

Η ουσιαστική συζήτηση δεν αφορά το αν ένα pattern είναι παλιό ή σύγχρονο. Αφορά την κατεύθυνση των εξαρτήσεων, τα αρχιτεκτονικά όρια, τη συντηρησιμότητα, τη δυνατότητα δοκιμών και τους συμβιβασμούς που αποδεχόμαστε συνειδητά όταν σχεδιάζουμε μια εφαρμογή.

Αν επιλέγουμε Clean Architecture, πρέπει να γνωρίζουμε γιατί την επιλέγουμε εξαρχής.

1. Η Clean Architecture αφορά την κατεύθυνση των εξαρτήσεων

Η Clean Architecture δεν είναι απλώς μια δομή φακέλων με Domain, Application, Infrastructure και Presentation.

Σκοπός της είναι να διατηρεί τους επιχειρησιακούς κανόνες ανεξάρτητους από τις εξωτερικές τεχνικές λεπτομέρειες, όπως οι βάσεις δεδομένων, τα frameworks, τα user interfaces και οι υπηρεσίες υποδομής.

Ο Robert C. Martin περιγράφει αυτή την προσέγγιση στο άρθρο του The Clean Architecture.

Ένας από τους σημαντικότερους κανόνες είναι ο Dependency Rule:

Οι εξαρτήσεις του πηγαίου κώδικα πρέπει να κατευθύνονται προς τα μέσα, προς τις πολιτικές υψηλότερου επιπέδου.

Σε μια τυπική λύση .NET με Clean Architecture, οι εξαρτήσεις των projects μπορούν να αποτυπωθούν ως εξής:

flowchart TD
    Presentation --> Application
    Application --> Domain
    Infrastructure --> Application
    Infrastructure --> Domain

Το διάγραμμα παρουσιάζει τις εξαρτήσεις των projects και του πηγαίου κώδικα, όχι την κατεύθυνση των κλήσεων κατά την εκτέλεση.

Οι ευθύνες των layers είναι οι εξής:

Domain: Entities, Value Objects, domain services και επιχειρησιακοί κανόνες.
Application: Use cases, commands, queries, handlers και συμβόλαια που απαιτούν οι περιπτώσεις χρήσης.
Infrastructure: Entity Framework Core, πρόσβαση στη βάση δεδομένων, εξωτερικές υπηρεσίες και υλοποιήσεις των persistence contracts.
Presentation: Controllers, endpoints και το σημείο εισόδου της εφαρμογής.

Το Domain δεν πρέπει να εξαρτάται από το Application ή το Infrastructure. Το Application δεν πρέπει να εξαρτάται από τις υλοποιήσεις του Infrastructure. Αντίθετα, το Infrastructure μπορεί να εξαρτάται από abstractions που ορίζονται στα εσωτερικά layers.

Εδώ ακριβώς αποκτά σημασία το Repository Pattern.

2. Dependency Inversion Principle: Το σημαντικότερο σημείο

Το Dependency Inversion Principle (DIP) είναι μία από τις αρχές SOLID.

Σύμφωνα με αυτή, τα high-level modules δεν πρέπει να εξαρτώνται άμεσα από low-level modules. Και τα δύο πρέπει να εξαρτώνται από abstractions. Οι αφαιρέσεις δεν πρέπει να εξαρτώνται από τις λεπτομέρειες υλοποίησης· οι υλοποιήσεις πρέπει να εξαρτώνται από τις αφαιρέσεις.

Ας εξετάσουμε έναν handler που εξαρτάται άμεσα από το Entity Framework Core:

public sealed class CreateUserHandler
{
    private readonly AppDbContext _context;

    public CreateUserHandler(AppDbContext context)
    {
        _context = context;
    }

    public async Task HandleAsync(
        User user,
        CancellationToken cancellationToken)
    {
        _context.Users.Add(user);

        await _context.SaveChangesAsync(
            cancellationToken);
    }
}

Ο κώδικας είναι λειτουργικός. Δεν είναι εγγενώς λανθασμένος.

Ωστόσο, το application use case εξαρτάται άμεσα από το AppDbContext, το οποίο αποτελεί μέρος της υλοποίησης του persistence layer.

Επομένως, το Application project χρειάζεται αναφορά στο project ή assembly που περιέχει το συγκεκριμένο context και συνδέεται με την προσέγγιση persistence του EF Core.

Αν ο αρχιτεκτονικός μας στόχος είναι να διατηρήσουμε το Application ανεξάρτητο από την τεχνολογία αποθήκευσης, αυτή η εξάρτηση αποτελεί έναν σημαντικό συμβιβασμό.

Μπορούμε να εισαγάγουμε μια αφαίρεση:

public interface IUserRepository
{
    void Add(User user);
}

Το interface βρίσκεται στο Application, επειδή εκεί βρίσκεται το use case που το χρειάζεται.

Η υλοποίηση βρίσκεται στο Infrastructure:

public sealed class UserRepository : IUserRepository
{
    private readonly AppDbContext _context;

    public UserRepository(AppDbContext context)
    {
        _context = context;
    }

    public void Add(User user)
    {
        _context.Users.Add(user);
    }
}

Ο handler εξαρτάται πλέον από την αφαίρεση:

public sealed class CreateUserHandler
{
    private readonly IUserRepository _repository;

    public CreateUserHandler(
        IUserRepository repository)
    {
        _repository = repository;
    }

    public Task HandleAsync(
        User user,
        CancellationToken cancellationToken)
    {
        _repository.Add(user);

        return Task.CompletedTask;
    }
}

Το παράδειγμα παραλείπει σκόπιμα τον συντονισμό της αποθήκευσης. Αυτός πρέπει να αντιμετωπίζεται από την επιλεγμένη στρατηγική Unit of Work ή transactions.

Το σημαντικό σημείο είναι η σχέση των εξαρτήσεων:

classDiagram
    class CreateUserHandler {
        +HandleAsync()
    }

    class IUserRepository {
        <<interface>>
        +Add(User)
    }

    class UserRepository {
        +Add(User)
    }

    CreateUserHandler --> IUserRepository : εξαρτάται από
    UserRepository ..|> IUserRepository : υλοποιεί

Το Application ορίζει το συμβόλαιο που χρειάζεται. Το Infrastructure το υλοποιεί χρησιμοποιώντας EF Core.

Αυτή είναι εφαρμογή του Dependency Inversion στο persistence layer.

Το Repository Pattern δεν είναι ο μοναδικός τρόπος εφαρμογής του DIP. Είναι, όμως, ένας καθιερωμένος τρόπος δημιουργίας ενός σαφούς ορίου μεταξύ της εφαρμογής και της πρόσβασης στα δεδομένα.

3. «Μα το Entity Framework Core υλοποιεί ήδη Repository και Unit of Work»

Αυτό είναι το ισχυρότερο επιχείρημα εναντίον των custom repositories και αξίζει να εξεταστεί δίκαια.

Το Entity Framework Core παρέχει ήδη abstractions με συμπεριφορά αντίστοιχη του Repository και του Unit of Work.

Για παράδειγμα:

var user = await context.Users
    .FirstOrDefaultAsync(
        x => x.Id == userId,
        cancellationToken);

Το DbSet<T> παρέχει πρόσβαση σε σύνολα οντοτήτων και υποστηρίζει την ανάκτηση και τροποποίησή τους.

Το DbContext παρακολουθεί τις αλλαγές και συντονίζει την αποθήκευσή τους μέσω του SaveChangesAsync().

Για πολλές εφαρμογές, αυτό είναι απολύτως επαρκές.

Ένα custom Repository που απλώς περιτυλίγει κάθε μέθοδο του DbSet<T> μπορεί να προσθέτει boilerplate χωρίς ουσιαστικό διαχωρισμό.

Για παράδειγμα:

public interface IRepository<T>
    where T : class
{
    Task<T?> GetByIdAsync(Guid id);
    Task AddAsync(T entity);
    void Update(T entity);
    void Delete(T entity);
}

Αυτό το interface δεν είναι αυτομάτως κακό. Αν, όμως, απλώς αναπαράγει τις λειτουργίες του EF Core και εκθέτει παντού IQueryable<T>, ενδέχεται να προσφέρει ελάχιστη προστασία από την εξάρτηση της εφαρμογής από το persistence layer.

Το σωστό συμπέρασμα δεν είναι ότι τα repositories έχουν ξεπεραστεί.

Είναι ότι ένα Repository πρέπει να δικαιολογεί την ύπαρξή του μέσω του αρχιτεκτονικού ορίου ή της εξειδικευμένης συμπεριφοράς που προσφέρει.

Η Microsoft εξετάζει τόσο την προσέγγιση με repositories όσο και την απευθείας χρήση του DbContext στην τεκμηρίωση Implementing the persistence layer with Entity Framework Core.

Η τεκμηρίωση αναγνωρίζει ότι το EF Core παρέχει ήδη συμπεριφορά Repository και Unit of Work, ενώ παράλληλα εξηγεί γιατί τα custom repositories μπορούν να παραμένουν χρήσιμα, ιδιαίτερα σε πιο σύνθετες εφαρμογές.

4. Generic Repository ή Domain-Specific Repository;

Δεν προσφέρουν όλα τα repositories τον ίδιο βαθμό αφαίρεσης.

Ένα generic repository μπορεί να παρέχει τυπικές λειτουργίες CRUD:

public interface IRepository<T>
    where T : class
{
    Task<T?> GetByIdAsync(
        Guid id,
        CancellationToken cancellationToken);

    Task AddAsync(
        T entity,
        CancellationToken cancellationToken);

    void Remove(T entity);
}

Αυτό μπορεί να είναι χρήσιμο όταν οι λειτουργίες είναι πράγματι κοινές μεταξύ των οντοτήτων.

Ωστόσο, τα επιχειρησιακά domains σπάνια περιορίζονται σε απλές CRUD λειτουργίες.

Ας εξετάσουμε ένα σύστημα διαχείρισης χρηστών.

Μια λειτουργία μπορεί να χρειάζεται να ελέγξει αν υπάρχει ήδη ένα email, να ανακτήσει έναν χρήστη μαζί με τα σχετικά permissions ή να φορτώσει ένα aggregate για μια επιχειρησιακή ενέργεια.

Ένα domain-specific repository μπορεί να εκφράζει απευθείας αυτές τις ανάγκες:

public interface IUserRepository
{
    Task<User?> GetByIdAsync(
        Guid userId,
        CancellationToken cancellationToken);

    Task<bool> EmailExistsAsync(
        string email,
        CancellationToken cancellationToken);

    void Add(User user);
}

Η υλοποίηση μπορεί να χρησιμοποιεί τα καταλληλότερα queries του EF Core:

public sealed class UserRepository : IUserRepository
{
    private readonly AppDbContext _context;

    public UserRepository(AppDbContext context)
    {
        _context = context;
    }

    public Task<User?> GetByIdAsync(
        Guid userId,
        CancellationToken cancellationToken)
    {
        return _context.Users
            .FirstOrDefaultAsync(
                x => x.Id == userId,
                cancellationToken);
    }

    public Task<bool> EmailExistsAsync(
        string email,
        CancellationToken cancellationToken)
    {
        return _context.Users
            .AnyAsync(
                x => x.Email == email,
                cancellationToken);
    }

    public void Add(User user)
    {
        _context.Users.Add(user);
    }
}

Το Application εκφράζει τι χρειάζεται, χωρίς να γνωρίζει πώς υλοποιείται το query στη βάση δεδομένων.

Υπάρχει και μια δεύτερη σημαντική διάκριση: δεν είναι απαραίτητο να δημιουργούμε διαφορετικό Repository για κάθε use case.

Τα CreateUser, UpdateUser και GetUser μπορούν να χρησιμοποιούν το ίδιο IUserRepository, εφόσον εξυπηρετεί τις ανάγκες τους.

Σε εφαρμογές CQRS, οι command handlers μπορούν να χρησιμοποιούν repositories για την ανάκτηση και τροποποίηση aggregates, ενώ οι read handlers μπορούν να χρησιμοποιούν απευθείας projections του EF Core σε DTOs, εφόσον η αρχιτεκτονική επιτρέπει συνειδητά αυτή την εξάρτηση.

Στόχος δεν είναι να μεγιστοποιήσουμε τον αριθμό των repositories. Στόχος είναι να δημιουργήσουμε χρήσιμα και σαφή όρια.

5. Πού πρέπει να βρίσκονται τα Repository Interfaces;

Αυτό το ερώτημα συζητείται συχνά στις υλοποιήσεις Clean Architecture.

Δεν υπάρχει καθολικός κανόνας ότι κάθε repository interface πρέπει να ανήκει στο Domain project.

Η σωστή θέση εξαρτάται από την ευθύνη που εκφράζει το interface.

Επιλογή Α: Interfaces στο Application

Application/
    Users/
        IUserRepository.cs
        CreateUser/
            CreateUserCommand.cs
            CreateUserHandler.cs

Infrastructure/
    Persistence/
        UserRepository.cs
        AppDbContext.cs

Αυτός είναι ένας έγκυρος σχεδιασμός όταν το repository εκφράζει ένα συμβόλαιο πρόσβασης στα δεδομένα που απαιτούν τα application use cases.

Το Application ορίζει το συμβόλαιο και το Infrastructure παρέχει την υλοποίησή του.

Η προσέγγιση αυτή είναι ιδιαίτερα πρακτική σε εφαρμογές που οργανώνουν τη λειτουργικότητά τους ανά use case ή feature.

Επιλογή Β: Interfaces στο Domain

Domain/
    Users/
        User.cs
        IUserRepository.cs

Infrastructure/
    Persistence/
        UserRepository.cs

Και αυτή είναι έγκυρη επιλογή όταν το συμβόλαιο του repository θεωρείται μέρος του domain model, συχνά σε μια προσέγγιση Domain-Driven Design που οργανώνεται γύρω από aggregate roots.

Η ουσιαστική διάκριση αφορά την ιδιοκτησία του συμβολαίου: ποιο layer χρειάζεται την αφαίρεση και ποιο πρέπει να την ορίζει;

Η θέση του interface πρέπει να αντικατοπτρίζει αυτή την απόφαση, αντί να ακολουθεί έναν κανόνα σύμφωνα με τον οποίο όλα τα repositories πρέπει να βρίσκονται στο ίδιο project ανεξάρτητα από τον σκοπό τους.

6. Επιβάλλει η Clean Architecture τη χρήση custom repositories;

Όχι. Η Clean Architecture απαιτεί να τηρούνται τα όρια των εξαρτήσεων· δεν επιβάλλει μία συγκεκριμένη υλοποίηση Repository.

Αυτή η διάκριση είναι σημαντική.

Ας εξετάσουμε δύο διαφορετικές αρχιτεκτονικές.

Αρχιτεκτονική Α: Απευθείας χρήση EF Core

Application
    └── CreateUserHandler
            └── AppDbContext

Infrastructure
    └── EF Core configuration

Αυτή μπορεί να είναι λογική επιλογή για μια σχετικά απλή εφαρμογή, ιδιαίτερα όταν η ομάδα αποδέχεται συνειδητά την εξάρτηση του Application από το EF Core.

Μειώνει τον αριθμό των abstractions και των κλάσεων.

Ωστόσο, το Application συνδέεται πλέον με το persistence framework.

Αρχιτεκτονική Β: Custom Repository abstraction

Application
    ├── CreateUserHandler
    └── IUserRepository

Infrastructure
    ├── UserRepository
    └── AppDbContext

Αυτός ο σχεδιασμός εισάγει επιπλέον κώδικα και ένα επίπεδο έμμεσης πρόσβασης.

Ανταλλάσσει αυτή την πολυπλοκότητα με ένα συγκεκριμένο όφελος: το Application εξαρτάται από ένα συμβόλαιο που μπορεί να υλοποιηθεί ανεξάρτητα από το EF Core.

Το αν αυτή η επιπλέον απομόνωση αξίζει το κόστος εξαρτάται από τις απαιτήσεις του project.

Αν ο δηλωμένος στόχος είναι να παραμείνει το Application ανεξάρτητο από την τεχνολογία persistence, η δεύτερη αρχιτεκτονική εκφράζει πιο άμεσα αυτόν τον στόχο.

Αν ο στόχος είναι η ελαχιστοποίηση των abstractions σε μια μικρή εφαρμογή, η πρώτη επιλογή μπορεί να είναι προτιμότερη.

Πρόκειται για διαφορετικούς συμβιβασμούς, όχι για απόδειξη ότι ένα pattern έχει ξεπεραστεί.

7. Testing: Αρχιτεκτονικό όφελος, όχι μαγική λύση

Τα custom repositories μπορούν να διευκολύνουν τις δοκιμές των application use cases χωρίς σύνδεση σε production database.

Για παράδειγμα, ένας handler που εξαρτάται από το IUserRepository μπορεί να δοκιμαστεί με μια fake υλοποίηση ή ένα mock.

public sealed class FakeUserRepository : IUserRepository
{
    private readonly List<User> _users = [];

    public void Add(User user)
    {
        _users.Add(user);
    }

    public Task<User?> GetByIdAsync(
        Guid userId,
        CancellationToken cancellationToken)
    {
        return Task.FromResult(
            _users.FirstOrDefault(x => x.Id == userId));
    }

    public Task<bool> EmailExistsAsync(
        string email,
        CancellationToken cancellationToken)
    {
        return Task.FromResult(
            _users.Any(x => x.Email == email));
    }
}

Έτσι, μπορούμε να ελέγξουμε τη συμπεριφορά του Application ανεξάρτητα από την υποδομή της βάσης δεδομένων.

Ωστόσο, ένα fake repository δεν επιβεβαιώνει ότι η πραγματική υλοποίηση EF Core παράγει το σωστό query ή συμπεριφέρεται σωστά με τον επιλεγμένο database provider.

Για αυτές τις περιπτώσεις εξακολουθούν να απαιτούνται integration tests.

Η Microsoft εξηγεί αυτούς τους συμβιβασμούς στην τεκμηρίωσή της για την επιλογή στρατηγικής testing για το EF Core και για testing χωρίς την production database.

Το συμπέρασμα είναι απλό: τα repositories μπορούν να βελτιώσουν την απομόνωση των tests, αλλά δεν καταργούν την ανάγκη ελέγχου της συμπεριφοράς του persistence layer.

8. Τι γίνεται με το Unit of Work και τα transactions;

Οι συζητήσεις για τα repositories συχνά οδηγούν σε μια ακόμη παρανόηση: ότι η προσθήκη ενός Repository λύνει αυτομάτως τη διαχείριση συναλλαγών.

Δεν ισχύει κάτι τέτοιο.

Το DbContext του EF Core παρέχει ήδη συμπεριφορά Unit of Work. Το SaveChangesAsync() αποθηκεύει τις αλλαγές που παρακολουθεί το context και, στις συνήθεις περιπτώσεις όπου υποστηρίζονται συναλλαγές από τον provider, τις εκτελεί ατομικά μέσα σε transaction.

Ένα custom repository μπορεί να προσθέτει οντότητες στο context χωρίς να κάνει άμεση αποθήκευση:

repository.Add(user);
repository.Add(profile);

await unitOfWork.SaveChangesAsync(cancellationToken);

Αυτό μπορεί να κάνει πιο σαφή τη διαχείριση της αποθήκευσης και να συντονίσει πολλαπλά repositories στο πλαίσιο ενός Unit of Work.

Ωστόσο, ένα ξεχωριστό IUnitOfWork δεν είναι υποχρεωτικό απλώς και μόνο επειδή υπάρχουν repositories. Η αξία του εξαρτάται από το αν εκφράζει ένα χρήσιμο συμβόλαιο και από τον τρόπο που η εφαρμογή διαχειρίζεται την αποθήκευση και τα transactions.

Το σημαντικό είναι να γνωρίζουμε πού γίνεται το commit των αλλαγών και αν το συγκεκριμένο use case απαιτεί ατομικότητα.

9. Η ευθύνη του Architect: Να εξηγεί τους συμβιβασμούς

Ένας senior developer ή software architect πρέπει να μπορεί να εξηγήσει τις συνέπειες μιας σχεδιαστικής απόφασης και όχι απλώς να χαρακτηρίζει ένα pattern παλιό ή σύγχρονο.

Μια ουσιαστική αρχιτεκτονική αξιολόγηση πρέπει να εξετάζει:

Εξαρτάται το Application από υλοποιήσεις του Infrastructure;
Εκφράζουν τα interfaces πραγματικές ανάγκες του Application ή του Domain;
Κρύβουν τα repositories τις λεπτομέρειες του persistence ή απλώς αναπαράγουν το DbSet<T>;
Είναι σαφείς οι ευθύνες των queries;
Μπορεί η ομάδα να δοκιμάσει τη συμπεριφορά του Application χωρίς να συνδέει αναγκαστικά κάθε test με τη βάση δεδομένων;
Δικαιολογείται το πρόσθετο κόστος συντήρησης των abstractions;

Αυτά τα ερωτήματα οδηγούν σε μια πολύ πιο χρήσιμη τεχνική συζήτηση από το αν το Repository Pattern είναι ακόμη στη μόδα.

Η ίδια αρχή ισχύει για πολλές αρχιτεκτονικές αποφάσεις. Ένα pattern δεν είναι πολύτιμο απλώς επειδή έχει συγκεκριμένο όνομα. Ούτε είναι άχρηστο επειδή ένα framework παρέχει παρόμοια λειτουργικότητα.

10. Συμπεράσματα

Το Entity Framework Core παρέχει ήδη λειτουργίες αντίστοιχες με Repository και Unit of Work. Αυτό το γεγονός πρέπει να επηρεάζει τις σχεδιαστικές μας αποφάσεις.

Δεν πρέπει, όμως, να τερματίζει τη συζήτηση.

Όταν επιλέγουμε Clean Architecture, πρέπει να κατανοούμε τα αρχιτεκτονικά όρια που θέλουμε να διατηρήσουμε. Η κατεύθυνση των εξαρτήσεων είναι θεμελιώδης για αυτόν τον σχεδιασμό και το Dependency Inversion είναι μία από τις αρχές που βοηθούν στη διατήρησή του.

Ένα custom Repository δεν είναι υποχρεωτικό σε κάθε .NET εφαρμογή. Ένα generic repository που δεν προσφέρει ουσιαστική απομόνωση μπορεί να μετατραπεί σε περιττό boilerplate.

Ένα προσεκτικά σχεδιασμένο Repository, όμως, μπορεί να παρέχει σαφές συμβόλαιο πρόσβασης στα δεδομένα, να προστατεύει το Application από εξαρτήσεις στο EF Core, να υποστηρίζει στοχευμένα tests και να διευκολύνει τη μελλοντική εξέλιξη του συστήματος.

Το ερώτημα δεν είναι αν το Repository Pattern έχει ξεπεραστεί. Το ερώτημα είναι αν η αφαίρεση εξυπηρετεί έναν σαφή αρχιτεκτονικό σκοπό στο σύστημα που κατασκευάζουμε.

Αυτή είναι η διαφορά ανάμεσα στην τυφλή εφαρμογή ενός pattern και στην τεκμηριωμένη αρχιτεκτονική απόφαση.

Πηγές

Robert C. Martin, The Clean Architecture.
Microsoft, Implementing the persistence layer with Entity Framework Core.
Microsoft, Choosing a testing strategy.
Microsoft, Testing without your production database system.

Repository Pattern in .NET: Is It Really Obsolete Because Entity Framework Core Already Implements It?

nikosst — Fri, 09 Oct 2026 18:55:46 +0000

Understanding Clean Architecture, Dependency Inversion, persistence boundaries, and the real trade-offs behind custom repositories.

Introduction

Every few years, the same discussion appears in .NET development communities:

"Why are you using the Repository Pattern? Entity Framework Core already implements a Repository and Unit of Work. Your abstraction is unnecessary and outdated."

At first glance, this argument sounds reasonable. Entity Framework Core provides DbSet<T> for working with entities and DbContext for tracking changes and persisting them. Why introduce additional interfaces and classes that appear to do the same thing?

However, this discussion often mixes two different questions:

Does Entity Framework Core provide repository-like and unit-of-work capabilities?
Does that mean a custom repository has no architectural value?

The answer to the first question is yes. The answer to the second is no.

The real discussion is not about whether a pattern is old or new. It is about dependency direction, architectural boundaries, maintainability, testability, and the trade-offs we consciously accept when designing an application.

If we choose Clean Architecture, we should understand why we chose it in the first place.

1. Clean Architecture Is About Dependency Direction

Clean Architecture is not simply a folder structure containing Domain, Application, Infrastructure, and Presentation.

Its purpose is to keep business rules independent of external technical details, such as databases, frameworks, user interfaces, and infrastructure services.

Robert C. Martin describes this principle in his article, The Clean Architecture.

One of the most important rules is the Dependency Rule:

Source code dependencies must point inward, toward higher-level policies.

In a typical .NET Clean Architecture solution, the dependency relationships look like this:

flowchart TD
    Presentation --> Application
    Application --> Domain
    Infrastructure --> Application
    Infrastructure --> Domain

This diagram represents project and source-code dependencies, not the direction of runtime calls.

The responsibilities are straightforward:

Domain: Entities, value objects, domain services, and business rules.
Application: Use cases, commands, queries, handlers, and application-level contracts.
Infrastructure: Entity Framework Core, database access, external services, and implementations of persistence contracts.
Presentation: Controllers, endpoints, and the user-facing entry point.

The Domain should not depend on the Application or Infrastructure. The Application should not depend on Infrastructure implementations. Infrastructure can depend on the abstractions defined by the inner layers.

This is where the Repository Pattern becomes relevant.

2. Dependency Inversion Principle: The Important Part

The Dependency Inversion Principle (DIP) is one of the SOLID principles.

It states that high-level modules should not depend directly on low-level modules. Both should depend on abstractions. Those abstractions should not depend on implementation details; implementations should depend on abstractions.

Consider an application handler that directly depends on Entity Framework Core:

public sealed class CreateUserHandler
{
    private readonly AppDbContext _context;

    public CreateUserHandler(AppDbContext context)
    {
        _context = context;
    }

    public async Task HandleAsync(
        User user,
        CancellationToken cancellationToken)
    {
        _context.Users.Add(user);

        await _context.SaveChangesAsync(
            cancellationToken);
    }
}

This code is perfectly functional. It is not inherently incorrect C#.

However, the application use case directly depends on AppDbContext, which belongs to the persistence implementation.

Consequently, the Application project needs a reference to the project or assembly containing that context, and it becomes coupled to the EF Core persistence approach.

If our architectural goal is to keep Application independent of the persistence technology, this is an important trade-off.

We can introduce an abstraction instead.

public interface IUserRepository
{
    void Add(User user);
}

The interface belongs to the Application layer, where the use case needs it.

The implementation belongs to Infrastructure:

public sealed class UserRepository : IUserRepository
{
    private readonly AppDbContext _context;

    public UserRepository(AppDbContext context)
    {
        _context = context;
    }

    public void Add(User user)
    {
        _context.Users.Add(user);
    }
}

The handler now depends on the abstraction:

public sealed class CreateUserHandler
{
    private readonly IUserRepository _repository;

    public CreateUserHandler(
        IUserRepository repository)
    {
        _repository = repository;
    }

    public Task HandleAsync(
        User user,
        CancellationToken cancellationToken)
    {
        _repository.Add(user);

        return Task.CompletedTask;
    }
}

The example intentionally omits persistence coordination, which must be handled by the application's chosen unit-of-work or transaction strategy.

The important point is the dependency relationship:

classDiagram
    class CreateUserHandler {
        +HandleAsync()
    }

    class IUserRepository {
        <<interface>>
        +Add(User)
    }

    class UserRepository {
        +Add(User)
    }

    CreateUserHandler --> IUserRepository : depends on
    UserRepository ..|> IUserRepository : implements

The Application layer defines the contract it requires. Infrastructure implements that contract using EF Core.

This is dependency inversion applied to persistence.

The Repository Pattern is not the only way to achieve dependency inversion. However, it is a well-established way to create a persistence boundary.

3. "But Entity Framework Core Already Implements Repository and Unit of Work"

This is the strongest argument against introducing custom repositories, and it deserves a fair explanation.

Entity Framework Core already provides abstractions with repository-like and unit-of-work behavior.

For example:

var user = await context.Users
    .FirstOrDefaultAsync(
        x => x.Id == userId,
        cancellationToken);

DbSet<T> provides access to entity sets and supports querying and modifying entities.

DbContext tracks changes and coordinates their persistence through SaveChangesAsync().

For many applications, this is entirely sufficient.

A custom repository that merely wraps every DbSet<T> method may add boilerplate without providing meaningful separation.

For example:

public interface IRepository<T>
    where T : class
{
    Task<T?> GetByIdAsync(Guid id);
    Task AddAsync(T entity);
    void Update(T entity);
    void Delete(T entity);
}

This interface is not automatically bad. However, if it simply reproduces EF Core operations and exposes IQueryable<T> everywhere, the abstraction may provide little protection against persistence coupling.

The correct conclusion is not that repositories are obsolete.

It is that a repository should justify its existence by the architectural boundary or domain-specific behavior it provides.

Microsoft discusses both the repository approach and direct use of DbContext in its documentation on implementing the persistence layer with Entity Framework Core.

The documentation recognizes that EF Core already implements repository and unit-of-work capabilities while explaining why custom repositories can still be valuable, particularly in more complex applications.

4. Generic Repositories Versus Domain-Specific Repositories

Not all repositories provide the same level of abstraction.

A generic repository might expose standard CRUD operations:

public interface IRepository<T>
    where T : class
{
    Task<T?> GetByIdAsync(
        Guid id,
        CancellationToken cancellationToken);

    Task AddAsync(
        T entity,
        CancellationToken cancellationToken);

    void Remove(T entity);
}

This may be useful when the operations are genuinely common across entities.

However, business domains rarely remain limited to simple CRUD operations.

Consider a user management system.

A user-related operation might need to determine whether an email address already exists, retrieve a user together with relevant permissions, or load an aggregate for a business operation.

A domain-specific repository can express these requirements directly:

public interface IUserRepository
{
    Task<User?> GetByIdAsync(
        Guid userId,
        CancellationToken cancellationToken);

    Task<bool> EmailExistsAsync(
        string email,
        CancellationToken cancellationToken);

    void Add(User user);
}

The implementation can use the most appropriate EF Core queries:

public sealed class UserRepository : IUserRepository
{
    private readonly AppDbContext _context;

    public UserRepository(AppDbContext context)
    {
        _context = context;
    }

    public Task<User?> GetByIdAsync(
        Guid userId,
        CancellationToken cancellationToken)
    {
        return _context.Users
            .FirstOrDefaultAsync(
                x => x.Id == userId,
                cancellationToken);
    }

    public Task<bool> EmailExistsAsync(
        string email,
        CancellationToken cancellationToken)
    {
        return _context.Users
            .AnyAsync(
                x => x.Email == email,
                cancellationToken);
    }

    public void Add(User user)
    {
        _context.Users.Add(user);
    }
}

The Application layer expresses what it needs without knowing how the database query is implemented.

There is another important distinction: a repository should not necessarily be created for every use case.

CreateUser, UpdateUser, and GetUser can use the same IUserRepository if they need the same persistence boundary.

For CQRS applications, command handlers may use repositories to load and modify aggregates, while read handlers may use direct EF Core projections into DTOs if the architecture deliberately allows that dependency.

The objective is not to maximize the number of repositories. It is to establish useful and explicit boundaries.

5. Where Should Repository Interfaces Live?

This question is frequently debated in Clean Architecture implementations.

There is no universal rule that every repository interface must belong to the Domain project.

The correct location depends on the responsibility represented by the interface.

Option A: Interfaces in Application

Application/
    Users/
        IUserRepository.cs
        CreateUser/
            CreateUserCommand.cs
            CreateUserHandler.cs

Infrastructure/
    Persistence/
        UserRepository.cs
        AppDbContext.cs

This is a valid design when the repository represents an application-level persistence contract required by use cases.

The Application layer defines the contract, and Infrastructure provides its implementation.

This approach is particularly straightforward in applications that organize functionality by use case or feature.

Option B: Interfaces in Domain

Domain/
    Users/
        User.cs
        IUserRepository.cs

Infrastructure/
    Persistence/
        UserRepository.cs

This is also a valid design when the repository contract is considered part of the domain model, often in a Domain-Driven Design approach involving aggregate roots.

The key distinction is semantic ownership: which layer needs the abstraction, and which layer should own its contract?

The interface's location should reflect that decision rather than follow a rule that every repository must live in the same project regardless of its purpose.

6. Does Clean Architecture Require Custom Repositories?

No. Clean Architecture requires the dependency boundaries to be respected; it does not mandate a particular repository implementation.

This distinction is important.

Consider two possible architectures.

Architecture A: Direct EF Core access

Application
    └── CreateUserHandler
            └── AppDbContext

Infrastructure
    └── EF Core configuration

This can be a reasonable choice for a relatively simple application, especially when the team deliberately accepts EF Core as an Application dependency.

It reduces the number of abstractions and classes.

However, the Application layer is now coupled to the persistence framework.

Architecture B: Custom repository abstraction

Application
    ├── CreateUserHandler
    └── IUserRepository

Infrastructure
    ├── UserRepository
    └── AppDbContext

This design introduces additional code and indirection.

In return, the Application layer depends on a contract that can be implemented independently of EF Core.

Whether that additional separation is worth its cost depends on the project's requirements.

If the stated goal is to keep the Application layer independent of persistence technology, Architecture B expresses that goal more directly.

If the goal is to minimize abstractions in a small application, Architecture A may be preferable.

These are different trade-offs, not proof that one pattern has become obsolete.

7. Testing: An Architectural Benefit, Not a Magic Solution

Custom repositories can make application use cases easier to test without connecting to a production database.

For example, a handler that depends on IUserRepository can be tested with a fake implementation or a mock.

public sealed class FakeUserRepository : IUserRepository
{
    private readonly List<User> _users = [];

    public void Add(User user)
    {
        _users.Add(user);
    }

    public Task<User?> GetByIdAsync(
        Guid userId,
        CancellationToken cancellationToken)
    {
        return Task.FromResult(
            _users.FirstOrDefault(x => x.Id == userId));
    }

    public Task<bool> EmailExistsAsync(
        string email,
        CancellationToken cancellationToken)
    {
        return Task.FromResult(
            _users.Any(x => x.Email == email));
    }
}

This allows the application behavior to be tested independently of database infrastructure.

However, a fake repository does not verify that the actual EF Core implementation generates the correct query or behaves correctly against the selected database provider.

Those concerns still require integration testing.

Microsoft explains these trade-offs in its guidance on choosing a testing strategy for EF Core and testing without your production database.

The lesson is straightforward: repositories can improve test isolation, but they do not eliminate the need to test persistence behavior.

8. What About Unit of Work and Transactions?

Repository discussions often introduce another misconception: that adding a repository automatically solves transaction management.

It does not.

EF Core's DbContext already provides unit-of-work behavior. Calling SaveChangesAsync() persists the tracked changes, normally within a transaction when the provider supports transactions.

A custom repository may add entities to the context without saving immediately:

repository.Add(user);
repository.Add(profile);

await unitOfWork.SaveChangesAsync(cancellationToken);

This can make the persistence boundary explicit and coordinate multiple repositories within one unit of work.

However, adding a separate IUnitOfWork interface is not mandatory merely because repositories exist. Its value depends on whether it expresses a useful application-level contract and how the application manages persistence and transactions.

The important thing is to understand where changes are committed and whether the use case requires atomicity.

9. The Architect's Responsibility: Explain the Trade-Off

A senior developer or software architect should be able to explain the consequences of a design decision, not simply label a pattern as old or modern.

A useful review should ask:

Does the Application layer depend on infrastructure-specific implementations?
Do the interfaces express meaningful application or domain requirements?
Are repositories hiding persistence details or merely duplicating DbSet<T>?
Are query responsibilities clear?
Can the team test application behavior without unnecessarily coupling tests to the database?
Does the additional abstraction justify its maintenance cost?

These questions lead to a more useful technical discussion than asking whether the Repository Pattern is still fashionable.

The same principle applies to many architectural decisions. A pattern is not valuable simply because it has a name, and it is not useless simply because a framework already provides similar functionality.

10. Final Thoughts

Entity Framework Core already provides repository-like and unit-of-work capabilities. That fact should influence our design decisions.

It should not, however, end the discussion.

When we choose Clean Architecture, we should understand the architectural boundaries we want to preserve. Dependency direction is fundamental to that design, and Dependency Inversion is one of the principles that helps maintain it.

A custom repository is not mandatory in every .NET application. A generic repository that adds no meaningful separation can become unnecessary boilerplate.

But a carefully designed repository can provide a clear persistence contract, protect the Application layer from EF Core dependencies, support focused testing, and make the system easier to evolve.

The question is not whether the Repository Pattern is obsolete. The question is whether the abstraction serves a clear architectural purpose in the system you are building.

That is the difference between applying a pattern mechanically and making an informed architectural decision.

References

Robert C. Martin, The Clean Architecture.
Microsoft, Implementing the persistence layer with Entity Framework Core.
Microsoft, Choosing a testing strategy.
Microsoft, Testing without your production database system.

Result Pattern στο ASP.NET Core: Πώς να διαχειριζόμαστε επιτυχίες και αποτυχίες χωρίς να βασιζόμαστε στα Exceptions

nikosst — Fri, 09 Oct 2026 14:29:36 +0000

Εισαγωγή

Ένα από τα σημαντικότερα ζητήματα στον σχεδιασμό μιας σύγχρονης εφαρμογής είναι ο τρόπος με τον οποίο διαχειριζόμαστε τις αποτυχίες.

Στην καθημερινότητα ενός .NET developer, αρκετές λειτουργίες μπορούν να αποτύχουν για απολύτως αναμενόμενους λόγους.

Για παράδειγμα:

Ένας χρήστης προσπαθεί να εγγραφεί με email που υπάρχει ήδη.

Ένα προϊόν δεν βρίσκεται στη βάση δεδομένων.

Μια παραγγελία δεν μπορεί να ολοκληρωθεί επειδή δεν υπάρχει διαθέσιμο απόθεμα.

Ένας χρήστης προσπαθεί να εκτελέσει μια ενέργεια για την οποία δεν έχει δικαιώματα.

Μια πληρωμή απορρίπτεται από τον πάροχο πληρωμών.

Σε όλες αυτές τις περιπτώσεις, η εφαρμογή δεν αντιμετωπίζει απαραίτητα κάποιο τεχνικό πρόβλημα. Αντίθετα, πρόκειται για αναμενόμενα αποτελέσματα της επιχειρησιακής λογικής.

Παρόλα αυτά, σε πολλές εφαρμογές χρησιμοποιούμε exceptions για να εκφράσουμε ακόμη και αυτές τις αναμενόμενες καταστάσεις.

Είναι όμως αυτή η καλύτερη επιλογή;

Εδώ έρχεται το Result Pattern.

Το Result Pattern είναι μια προσέγγιση σχεδιασμού που επιτρέπει σε μια μέθοδο να επιστρέφει ρητά είτε ένα επιτυχημένο αποτέλεσμα είτε μια αποτυχία, χωρίς να χρησιμοποιεί exceptions ως τον συνηθισμένο μηχανισμό ελέγχου ροής.

Στο άρθρο αυτό θα εξετάσουμε:

Ποιο πρόβλημα προσπαθεί να λύσει το Result Pattern.

Πώς λειτουργεί και ποιες αρχές κρύβονται πίσω του.

Πώς υλοποιούμε μια δική μας, strongly typed έκδοση σε C#.

Πώς το ενσωματώνουμε σε ASP.NET Core Web APIs.

Πώς συνδέεται με Clean Architecture, CQRS και Domain-Driven Design.

Πώς διαχειριζόμαστε validation, errors και HTTP status codes.

Πώς γράφουμε unit tests.

Πότε αξίζει να το χρησιμοποιούμε και πότε όχι.

Στόχος δεν είναι απλώς να δημιουργήσουμε μια κλάση Result, αλλά να κατανοήσουμε πώς αυτή η επιλογή επηρεάζει την αρχιτεκτονική και τη συντηρησιμότητα μιας εφαρμογής.

Το πρόβλημα: Exceptions για αναμενόμενες αποτυχίες

Ας ξεκινήσουμε με ένα απλό παράδειγμα.

Έχουμε μια εφαρμογή στην οποία οι χρήστες μπορούν να δημιουργήσουν λογαριασμό.

Ένας βασικός κανόνας είναι ότι δεν επιτρέπονται δύο χρήστες με το ίδιο email.

Μια συνηθισμένη υλοποίηση θα μπορούσε να είναι η εξής:

public async Task RegisterAsync(
string email,
CancellationToken cancellationToken)
{
var existingUser = await _userRepository
.GetByEmailAsync(email, cancellationToken);

if (existingUser is not null)
{
    throw new Exception("Email already exists");
}

var user = new User(email);

await _userRepository.AddAsync(
    user,
    cancellationToken);

return user;

}

Ο κώδικας είναι απλός και λειτουργικός.

Ωστόσο, κρύβει ορισμένα σημαντικά προβλήματα.

1.1 Η υπογραφή της μεθόδου δεν αποκαλύπτει όλες τις πιθανές εκβάσεις

Παρατηρούμε την υπογραφή:

Task RegisterAsync(...)

Από αυτήν καταλαβαίνουμε ότι η μέθοδος επιστρέφει έναν User.

Δεν γνωρίζουμε όμως ότι μπορεί να αποτύχει επειδή το email χρησιμοποιείται ήδη.

Για να το ανακαλύψουμε, πρέπει να διαβάσουμε την υλοποίηση ή την τεκμηρίωση.

Αυτό γίνεται ιδιαίτερα προβληματικό σε μεγάλα συστήματα, όπου μια μέθοδος μπορεί να καλείται από πολλαπλά σημεία.

1.2 Τα exceptions γίνονται μέρος της κανονικής ροής

Το γεγονός ότι ένα email υπάρχει ήδη δεν είναι κάτι απρόβλεπτο.

Είναι ένας επιχειρησιακός κανόνας που γνωρίζουμε εκ των προτέρων.

Επομένως, η αποτυχία της εγγραφής αποτελεί φυσιολογική πιθανή έκβαση.

Αν χρησιμοποιούμε exceptions για τέτοιες περιπτώσεις, καταλήγουμε να αντιμετωπίζουμε αναμενόμενα αποτελέσματα σαν εξαιρετικές καταστάσεις.

1.3 Ο κώδικας που καλεί τη μέθοδο γίνεται πιο περίπλοκος

Ας δούμε πώς μπορεί να χρησιμοποιηθεί η προηγούμενη μέθοδος μέσα σε έναν controller:

[HttpPost]
public async Task Register(
RegisterRequest request,
CancellationToken cancellationToken)
{
try
{
var user = await _userService.RegisterAsync(
request.Email,
cancellationToken);

    return Ok(user);
}
catch (Exception)
{
    return BadRequest();
}

}

Η συγκεκριμένη υλοποίηση έχει ένα σοβαρό μειονέκτημα.

Όλα τα exceptions μετατρέπονται σε HTTP 400.

Αυτό σημαίνει ότι ακόμη και ένα database connection failure ή ένα απροσδόκητο NullReferenceException μπορεί να εμφανιστεί στον client ως λανθασμένο αίτημα.

Η εφαρμογή χάνει τη δυνατότητα να διαχωρίζει μια επιχειρησιακή αποτυχία από ένα τεχνικό σφάλμα.

1.4 Δεν έχουν όλες οι αποτυχίες την ίδια σημασία

Είναι σημαντικό να ξεχωρίσουμε δύο κατηγορίες:

Αναμενόμενες αποτυχίες

Το email υπάρχει ήδη.

Το προϊόν δεν βρέθηκε.

Το υπόλοιπο δεν επαρκεί.

Η παραγγελία βρίσκεται σε κατάσταση που δεν επιτρέπει ακύρωση.

Απροσδόκητες αποτυχίες

Η βάση δεδομένων δεν είναι διαθέσιμη.

Παρουσιάστηκε σφάλμα προγραμματισμού.

Ένα εξωτερικό dependency επιστρέφει μη αναμενόμενη απάντηση.

Παραβιάστηκε μια εσωτερική τεχνική υπόθεση.

Το Result Pattern είναι ιδιαίτερα χρήσιμο για την πρώτη κατηγορία.

Δεν σημαίνει ότι πρέπει να καταργήσουμε τα exceptions από την εφαρμογή μας.

Σημαίνει ότι πρέπει να χρησιμοποιούμε τον κατάλληλο μηχανισμό για κάθε κατηγορία αποτυχίας.

Τι είναι το Result Pattern;

Το Result Pattern είναι ένα μοτίβο σχεδιασμού σύμφωνα με το οποίο μια λειτουργία επιστρέφει ένα αντικείμενο που αναπαριστά το αποτέλεσμά της.

Αυτό το αντικείμενο μπορεί να βρίσκεται σε μία από δύο καταστάσεις:

Success: Η λειτουργία ολοκληρώθηκε επιτυχώς.

Failure: Η λειτουργία δεν ολοκληρώθηκε και επιστρέφεται πληροφορία για τον λόγο αποτυχίας.

Μια τυπική χρήση θα μπορούσε να είναι:

Result result =
await userService.RegisterAsync(
email,
cancellationToken);

if (result.IsFailure)
{
Console.WriteLine(result.Error.Description);
return;
}

User user = result.Value;

Το σημαντικό είναι ότι η πιθανότητα αποτυχίας εμφανίζεται πλέον στην υπογραφή:

Task> RegisterAsync(...)

Ο caller γνωρίζει ότι δεν λαμβάνει απλώς έναν User, αλλά ένα αποτέλεσμα που πρέπει να αξιολογήσει.

Αυτή η ιδέα συνδέεται με τις έννοιες Either και Result που συναντάμε στον functional programming κόσμο.

Στη C#, όπου δεν υπάρχει ενσωματωμένος γενικός discriminated union τύπος με πλήρη exhaustiveness checking, μπορούμε να προσεγγίσουμε αυτή τη συμπεριφορά με δικούς μας τύπους.

Μια σημαντική διευκρίνιση

Το Result Pattern δεν εξαναγκάζει από μόνο του τον caller να ελέγξει την αποτυχία.

Η C# εξακολουθεί να επιτρέπει σε κάποιον να αγνοήσει ένα επιστρεφόμενο αποτέλεσμα.

Επιπλέον, ένα χειροποίητο Result δεν παρέχει αυτόματα compile-time exhaustiveness checking.

Το βασικό πλεονέκτημα είναι ότι η αποτυχία γίνεται ρητό μέρος του συμβολαίου της μεθόδου, αντί να παραμένει κρυμμένη σε κάποιο exception path.

Σχεδιάζοντας το Error Model

Πριν δημιουργήσουμε το Result, πρέπει να αποφασίσουμε πώς θα αναπαριστούμε τα errors.

Μια πρώτη προσέγγιση θα ήταν να επιστρέφουμε απλώς ένα string:

return Result.Failure(
"Email already exists");

Αυτό λειτουργεί, αλλά έχει περιορισμούς.

Ένα string δεν περιγράφει με δομημένο τρόπο το είδος του σφάλματος.

Επίσης, αν κάποιος αλλάξει το μήνυμα, μπορεί να επηρεάσει κώδικα που βασίζεται στο συγκεκριμένο κείμενο.

Για παράδειγμα, δεν θα θέλαμε να γράφουμε:

if (result.Error == "Email already exists")
{
// Handle duplicate email
}

Πρόκειται για εύθραυστο συμβόλαιο.

Αντίθετα, θα δημιουργήσουμε ένα strongly typed error model.

3.1 ErrorType

Αρχικά ορίζουμε τις βασικές κατηγορίες σφαλμάτων.

public enum ErrorType
{
Failure,
Validation,
NotFound,
Conflict,
Forbidden,
Unauthorized
}

Κάθε κατηγορία εκφράζει μια διαφορετική σημασιολογία.

Για παράδειγμα, το NotFound σημαίνει ότι ο πόρος που αναζητούμε δεν υπάρχει, ενώ το Conflict σημαίνει ότι η λειτουργία συγκρούεται με την τρέχουσα κατάσταση του συστήματος.

3.2 Error

Στη συνέχεια δημιουργούμε τον τύπο Error.

public sealed record Error(
string Code,
string Description,
ErrorType Type)
{
public static Error Failure(
string code,
string description) =>
new(code, description, ErrorType.Failure);

public static Error Validation(
    string code,
    string description) =>
    new(code, description, ErrorType.Validation);

public static Error NotFound(
    string code,
    string description) =>
    new(code, description, ErrorType.NotFound);

public static Error Conflict(
    string code,
    string description) =>
    new(code, description, ErrorType.Conflict);

public static Error Forbidden(
    string code,
    string description) =>
    new(code, description, ErrorType.Forbidden);

public static Error Unauthorized(
    string code,
    string description) =>
    new(code, description, ErrorType.Unauthorized);

}

Χρησιμοποιούμε record επειδή θέλουμε value-based equality.

Δύο errors με τα ίδια δεδομένα θεωρούνται ισοδύναμα.

Επίσης, το Error είναι immutable, γεγονός που περιορίζει την πιθανότητα ανεπιθύμητων αλλαγών μετά τη δημιουργία του.

3.3 Γιατί χρειαζόμαστε Code και Description;

Ας εξετάσουμε το ακόλουθο error:

public static readonly Error EmailAlreadyExists =
Error.Conflict(
"Users.EmailAlreadyExists",
"A user with this email already exists.");

Το Code είναι ένα σταθερό αναγνωριστικό.

Μπορεί να χρησιμοποιηθεί για:

Error handling.

Client-side translations.

Monitoring.

Structured logging.

Automated tests.

Το Description είναι το μήνυμα που περιγράφει το πρόβλημα.

Ο διαχωρισμός είναι σημαντικός επειδή το κείμενο ενός μηνύματος μπορεί να αλλάξει, ενώ το error code πρέπει ιδανικά να παραμένει σταθερό.

Σε ένα production API, τα codes πρέπει να θεωρούνται μέρος του συμβολαίου προς τους clients.

Υλοποιώντας το Result Pattern σε C#

Ας περάσουμε στην κεντρική υλοποίηση.

Θα δημιουργήσουμε δύο τύπους:

Result για λειτουργίες που δεν επιστρέφουν τιμή.

Result για λειτουργίες που επιστρέφουν δεδομένα.

Η διάκριση είναι χρήσιμη.

Μια λειτουργία διαγραφής, για παράδειγμα, μπορεί να χρειάζεται μόνο να μας ενημερώσει αν ολοκληρώθηκε.

Αντίθετα, μια λειτουργία δημιουργίας χρήστη χρειάζεται να επιστρέψει και το αναγνωριστικό του νέου χρήστη.

4.1 Η βασική κλάση Result

public class Result
{
public bool IsSuccess { get; }

public bool IsFailure => !IsSuccess;

public Error? Error { get; }

protected Result(bool isSuccess, Error? error)
{
    if (isSuccess && error is not null)
    {
        throw new ArgumentException(
            "A successful result cannot contain an error.");
    }

    if (!isSuccess && error is null)
    {
        throw new ArgumentException(
            "A failed result must contain an error.");
    }

    IsSuccess = isSuccess;
    Error = error;
}

public static Result Success() =>
    new(true, null);

public static Result Failure(Error error) =>
    new(false, error);

public static Result<T> Success<T>(T value) =>
    Result<T>.Success(value);

public static Result<T> Failure<T>(Error error) =>
    Result<T>.Failure(error);

}

Η σημαντικότερη λεπτομέρεια βρίσκεται στον constructor.

Δεν επιτρέπουμε να δημιουργηθεί ένα επιτυχημένο αποτέλεσμα που περιέχει error.

Ούτε επιτρέπουμε να δημιουργηθεί αποτυχημένο αποτέλεσμα χωρίς error.

Αυτές οι συνθήκες είναι τα invariants του τύπου μας.

Με άλλα λόγια, ορίζουμε ποιες καταστάσεις θεωρούνται έγκυρες και αποτρέπουμε τη δημιουργία μη έγκυρων αντικειμένων.

4.2 Το generic Result

public sealed class Result : Result
{
private readonly T? _value;

private Result(
    bool isSuccess,
    T? value,
    Error? error)
    : base(isSuccess, error)
{
    _value = value;
}

public T Value =>
    IsSuccess
        ? _value!
        : throw new InvalidOperationException(
            "Cannot access the value of a failed result.");

public static Result<T> Success(T value) =>
    new(true, value, null);

public static new Result<T> Failure(Error error) =>
    new(false, default, error);

}

Εδώ εισάγουμε μια σημαντική αρχή.

Το Value είναι διαθέσιμο μόνο όταν το αποτέλεσμα είναι επιτυχημένο.

Αν προσπαθήσουμε να το διαβάσουμε σε αποτυχημένο αποτέλεσμα, δημιουργείται InvalidOperationException.

Μπορεί αυτό να φαίνεται αντιφατικό;

Αφού προσπαθούμε να αποφύγουμε τα exceptions, γιατί χρησιμοποιούμε ένα μέσα στο Result;

Η απάντηση βρίσκεται στη διάκριση ανάμεσα στις αναμενόμενες επιχειρησιακές αποτυχίες και στη λανθασμένη χρήση ενός API.

Το να μην υπάρχει ένας χρήστης στη βάση δεδομένων είναι αναμενόμενο.

Το να προσπαθήσει ένας developer να διαβάσει το Value από ένα αποτυχημένο Result παραβιάζει το συμβόλαιο του τύπου.

Το δεύτερο αποτελεί programming error.

Senior-level σημείωση: Η παραπάνω υλοποίηση είναι σκόπιμα μικρή για εκπαιδευτικούς λόγους. Το T? και ο τελεστής ! δεν επιβάλλουν πραγματικό non-null invariant για reference types. Αν το συμβόλαιό μας απαγορεύει το Success(null), πρέπει να προσθέσουμε ρητό έλεγχο ή να επιλέξουμε διαφορετικό μοντέλο nullability. Επίσης, η ιδιότητα Error είναι nullable, οπότε ο compiler δεν μπορεί να συμπεράνει ότι μετά από IsFailure είναι μη-null.

Ορίζοντας Domain Errors

Μια καλή πρακτική είναι να ορίζουμε τα errors κοντά στο domain στο οποίο ανήκουν.

Για παράδειγμα:

public static class UserErrors
{
public static readonly Error EmailAlreadyExists =
Error.Conflict(
"Users.EmailAlreadyExists",
"A user with this email already exists.");

public static Error NotFound(Guid userId) =>
    Error.NotFound(
        "Users.NotFound",
        $"User with id '{userId}' was not found.");

public static readonly Error InvalidEmail =
    Error.Validation(
        "Users.InvalidEmail",
        "The provided email is invalid.");

}

Αυτό προσφέρει δύο σημαντικά οφέλη.

Πρώτον, τα errors είναι επαναχρησιμοποιήσιμα.

Δεύτερον, οι υπηρεσίες δεν χρειάζεται να γνωρίζουν πώς κατασκευάζεται κάθε error.

Μπορούν απλώς να επιστρέφουν ένα γνωστό, καλά ορισμένο domain error.

Παρατηρούμε επίσης ότι το NotFound είναι μέθοδος και όχι στατικό πεδίο, επειδή το description περιλαμβάνει δυναμική πληροφορία.

Σε πραγματικές εφαρμογές πρέπει να προσέχουμε ώστε τέτοια μηνύματα να μην αποκαλύπτουν προσωπικά δεδομένα ή εσωτερικές πληροφορίες.

Πρακτικό παράδειγμα: User Registration

Ας εφαρμόσουμε τώρα το Result Pattern σε ένα πιο ρεαλιστικό σενάριο.

Θέλουμε να δημιουργήσουμε μια λειτουργία εγγραφής χρήστη.

Η διαδικασία περιλαμβάνει:

Έλεγχο εγκυρότητας του email.

Έλεγχο αν υπάρχει ήδη χρήστης με το ίδιο email.

Δημιουργία του χρήστη.

Αποθήκευση στη βάση δεδομένων.

Επιστροφή του αναγνωριστικού.

6.1 Το Request

public sealed record RegisterUserRequest(
string Email);

6.2 Το Response

public sealed record RegisterUserResponse(
Guid UserId,
string Email);

6.3 Το Repository Contract

public interface IUserRepository
{
Task ExistsByEmailAsync(
string email,
CancellationToken cancellationToken);

Task AddAsync(
    User user,
    CancellationToken cancellationToken);

}

Για το παράδειγμα υποθέτουμε ότι το repository αποθηκεύει τον χρήστη κατά την κλήση AddAsync.

Σε μια εφαρμογή που χρησιμοποιεί Unit of Work, η αποθήκευση μπορεί να πραγματοποιείται αργότερα μέσω SaveChangesAsync.

6.4 Το Domain Entity

public sealed class User
{
public Guid Id { get; private set; }

public string Email { get; private set; }

private User(Guid id, string email)
{
    Id = id;
    Email = email;
}

public static User Create(string email)
{
    return new User(
        Guid.NewGuid(),
        email);
}

}

Για να παραμείνει το παράδειγμα εστιασμένο στο Result Pattern, κρατάμε την οντότητα απλή.

Σε ένα πιο αυστηρό domain model θα μπορούσαμε να χρησιμοποιήσουμε Email value object, ώστε να επιβάλλουμε την εγκυρότητα και την κανονικοποίηση της διεύθυνσης στο ίδιο το domain.

6.5 Το Application Service

public sealed class UserService
{
private readonly IUserRepository _userRepository;

public UserService(IUserRepository userRepository)
{
    _userRepository = userRepository;
}

public async Task<Result<RegisterUserResponse>> RegisterAsync(
    RegisterUserRequest request,
    CancellationToken cancellationToken)
{
    if (string.IsNullOrWhiteSpace(request.Email))
    {
        return Result.Failure<RegisterUserResponse>(
            UserErrors.InvalidEmail);
    }

    var normalizedEmail = request.Email
        .Trim()
        .ToLowerInvariant();

    var emailExists = await _userRepository
        .ExistsByEmailAsync(
            normalizedEmail,
            cancellationToken);

    if (emailExists)
    {
        return Result.Failure<RegisterUserResponse>(
            UserErrors.EmailAlreadyExists);
    }

    var user = User.Create(normalizedEmail);

    await _userRepository.AddAsync(
        user,
        cancellationToken);

    var response = new RegisterUserResponse(
        user.Id,
        user.Email);

    return Result.Success(response);
}

}

Ας εξετάσουμε προσεκτικά τι συμβαίνει.

Πρώτο βήμα: Validation

if (string.IsNullOrWhiteSpace(request.Email))
{
return Result.Failure(
UserErrors.InvalidEmail);
}

Αν το email είναι κενό, η μέθοδος επιστρέφει ένα αποτυχημένο Result.

Δεν δημιουργείται exception.

Ο caller μπορεί να ελέγξει το error και να αποφασίσει πώς θα αντιδράσει.

Ο έλεγχος αυτός δεν αποτελεί πλήρη email validation. Είναι απλώς ένας αρχικός έλεγχος για τις ανάγκες του παραδείγματος.

Δεύτερο βήμα: Business Rule

if (emailExists)
{
return Result.Failure(
UserErrors.EmailAlreadyExists);
}

Εδώ εφαρμόζουμε τον κανόνα ότι δεν επιτρέπονται διπλές εγγραφές με το ίδιο email.

Η αποτυχία είναι αναμενόμενη.

Επομένως, επιστρέφουμε Result αντί να κάνουμε throw.

Τρίτο βήμα: Success

return Result.Success(response);

Η μέθοδος ολοκληρώνεται με ένα επιτυχημένο Result που περιέχει το response.

Ο caller γνωρίζει ότι το Value είναι διαθέσιμο όταν το IsSuccess είναι true.

6.6 Ένα κρίσιμο production ζήτημα: Concurrency

Η προηγούμενη υλοποίηση περιέχει έναν κλασικό κίνδυνο.

Φανταστείτε δύο ταυτόχρονα requests με το ίδιο email.

Και τα δύο μπορούν να εκτελέσουν τον έλεγχο:

ExistsByEmailAsync(email)

Και τα δύο μπορεί να λάβουν false.

Στη συνέχεια, και τα δύο προσπαθούν να αποθηκεύσουν τον χρήστη.

Αυτό είναι ένα race condition.

Το Result Pattern δεν λύνει το συγκεκριμένο πρόβλημα.

Η πραγματική προστασία πρέπει να βρίσκεται και στη βάση δεδομένων, μέσω unique constraint ή unique index στο κανονικοποιημένο email.

Όταν προκύψει η συγκεκριμένη παραβίαση, το persistence layer μπορεί να την αναγνωρίσει και να τη μετατρέψει σε ένα γνωστό EmailAlreadyExists Result, εφόσον αυτό αποτελεί μέρος του συμβολαίου του.

Δεν πρέπει όμως να μετατρέπουμε κάθε DbUpdateException σε conflict.

Ένα DbUpdateException μπορεί να προκύψει για πολλούς διαφορετικούς λόγους.

Χρειάζεται provider-specific αναγνώριση της συγκεκριμένης παραβίασης και προσεκτικός χειρισμός.

Αυτή είναι μια σημαντική διάκριση ανάμεσα σε ένα εκπαιδευτικό παράδειγμα και μια production-ready υλοποίηση.

Ενσωμάτωση σε ASP.NET Core Web API

Μέχρι τώρα το Application Service επιστρέφει ένα Result.

Το επόμενο ερώτημα είναι πώς μετατρέπουμε αυτό το αποτέλεσμα σε HTTP response.

Για παράδειγμα:

Result

HTTP Status

Success

200 OK ή 201 Created

Validation

400 Bad Request

NotFound

404 Not Found

Conflict

409 Conflict

Unauthorized

401 Unauthorized

Forbidden

403 Forbidden

Ο πίνακας είναι μια ενδεικτική πολιτική mapping και όχι ένας απόλυτος κανόνας.

Για παράδειγμα, σε ένα API που χρησιμοποιεί model validation μπορεί να επιλεγεί HTTP 422 για συγκεκριμένες semantic validation failures.

Επίσης, η πραγματική authentication και authorization συμπεριφορά πρέπει να παραμένει συμβατή με το security pipeline του ASP.NET Core.

7.1 Γιατί δεν πρέπει να επιστρέφουμε IActionResult από το Application Layer;

Θα μπορούσαμε να γράψουμε:

public async Task RegisterAsync(...)

Ωστόσο, αυτό θα δημιουργούσε εξάρτηση του application layer από το ASP.NET Core.

Η επιχειρησιακή λογική θα γνώριζε πλέον για HTTP status codes και MVC abstractions.

Σε μια Clean Architecture προσέγγιση θέλουμε να αποφύγουμε αυτή την εξάρτηση.

Το application layer πρέπει να εκφράζει το αποτέλεσμα της λειτουργίας.

Το presentation layer πρέπει να αποφασίζει πώς θα το παρουσιάσει στον εξωτερικό κόσμο.

7.2 Mapping σε ProblemDetails

Το ASP.NET Core υποστηρίζει το ProblemDetails, ένα καθιερωμένο format για την αναπαράσταση HTTP API errors.

Μπορούμε να δημιουργήσουμε έναν κεντρικό mapper:

using Microsoft.AspNetCore.Mvc;

public static class ResultExtensions
{
public static IActionResult ToActionResult(
this Result result,
ControllerBase controller)
{
if (result.IsSuccess)
{
return controller.Ok(result.Value);
}

    var error = result.Error!;

    var statusCode = error.Type switch
    {
        ErrorType.Validation =>
            StatusCodes.Status400BadRequest,

        ErrorType.NotFound =>
            StatusCodes.Status404NotFound,

        ErrorType.Conflict =>
            StatusCodes.Status409Conflict,

        ErrorType.Unauthorized =>
            StatusCodes.Status401Unauthorized,

        ErrorType.Forbidden =>
            StatusCodes.Status403Forbidden,

        _ =>
            StatusCodes.Status400BadRequest
    };

    var problem = new ProblemDetails
    {
        Status = statusCode,
        Title = error.Code,
        Detail = error.Description
    };

    return new ObjectResult(problem)
    {
        StatusCode = statusCode,
        ContentTypes =
        {
            "application/problem+json"
        }
    };
}

}

Το ! χρησιμοποιείται επειδή ο compiler δεν μπορεί να συμπεράνει από το IsFailure ότι το Error είναι μη-null.

Η εγγύηση προκύπτει από τον constructor του Result.

Σε μεγαλύτερη υλοποίηση θα μπορούσαμε να χρησιμοποιήσουμε TryGetError, pattern matching ή ένα διαφορετικό union-like API ώστε να αποφύγουμε αυτόν τον τελεστή.

7.3 Ο Controller

Ο controller γίνεται πλέον αρκετά απλός.

[ApiController]
[Route("api/users")]
public sealed class UsersController : ControllerBase
{
private readonly UserService _userService;

public UsersController(UserService userService)
{
    _userService = userService;
}

[HttpPost]
public async Task<IActionResult> Register(
    RegisterUserRequest request,
    CancellationToken cancellationToken)
{
    var result = await _userService.RegisterAsync(
        request,
        cancellationToken);

    if (result.IsFailure)
    {
        return result.ToActionResult(this);
    }

    return Created(
        $"/api/users/{result.Value.UserId}",
        result.Value);
}

}

Παρατηρούμε ότι ο controller δεν γνωρίζει τις λεπτομέρειες των business rules.

Δεν χρειάζεται να ξέρει πώς γίνεται ο έλεγχος του email.

Ούτε χρειάζεται να κάνει catch ένα exception για κάθε αναμενόμενη αποτυχία.

Απλώς μετατρέπει το αποτέλεσμα της εφαρμογής σε HTTP response.

Για τη συγκεκριμένη λειτουργία δημιουργίας χρησιμοποιούμε 201 Created.

Αν το API διαθέτει endpoint ανάκτησης χρήστη, μπορούμε να χρησιμοποιήσουμε και CreatedAtAction ή CreatedAtRoute, ώστε να παράγουμε το resource location με βάση το routing configuration.

7.4 Παράδειγμα HTTP Response

Αν το email υπάρχει ήδη, το API μπορεί να επιστρέψει:

HTTP/1.1 409 Conflict
Content-Type: application/problem+json

{
"type": "about:blank",
"title": "Users.EmailAlreadyExists",
"status": 409,
"detail": "A user with this email already exists."
}

Αυτό το response είναι προβλέψιμο και μπορεί να καταναλωθεί από διαφορετικούς clients.

Το frontend μπορεί να βασίζεται στο error code αντί να συγκρίνει μηνύματα.

Για παράδειγμα:

if (problem.title === "Users.EmailAlreadyExists") {
showEmailAlreadyExistsMessage();
}

Σε μεγαλύτερα APIs θα ήταν προτιμότερο το error code να βρίσκεται σε ξεχωριστό extension property, όπως code, και το title να χρησιμοποιείται για μια σύντομη, ανθρώπινα αναγνώσιμη περιγραφή.

Result Pattern και Clean Architecture

Το Result Pattern ταιριάζει ιδιαίτερα καλά σε εφαρμογές που ακολουθούν Clean Architecture.

Μια τυπική δομή θα μπορούσε να είναι:

src/
├── MyApp.Domain/
│ ├── Entities/
│ └── Errors/
│
├── MyApp.Application/
│ ├── Abstractions/
│ ├── Users/
│ └── Common/
│ └── Results/
│
├── MyApp.Infrastructure/
│ ├── Persistence/
│ └── Repositories/
│
└── MyApp.Api/
├── Controllers/
└── Extensions/

Σε αυτή τη δομή, το Result βρίσκεται στο Application layer ή σε ένα μικρό κοινό abstraction assembly, εφόσον υπάρχει πραγματική ανάγκη να χρησιμοποιείται από περισσότερα layers.

Τα domain errors μπορούν να ορίζονται στο Domain layer όταν αντιπροσωπεύουν καθαρά domain concepts.

Ο HTTP mapper βρίσκεται στο API layer.

Το βασικό πλεονέκτημα είναι ότι διαχωρίζουμε τις ευθύνες.

Domain: Ποιοι επιχειρησιακοί κανόνες ισχύουν;

Application: Πώς εκτελείται ένα use case και ποια αποτελέσματα μπορεί να επιστρέψει;

Infrastructure: Πώς επικοινωνούμε με τη βάση δεδομένων και τα εξωτερικά συστήματα;

Presentation: Πώς μετατρέπουμε τα αποτελέσματα σε HTTP responses;

Το Result Pattern δεν επιβάλλει από μόνο του Clean Architecture, αλλά μπορεί να υποστηρίξει αποτελεσματικά τον διαχωρισμό των layers.

Result Pattern και CQRS

Αν χρησιμοποιούμε CQRS, μπορούμε να εφαρμόσουμε την ίδια προσέγγιση σε commands και queries.

Για παράδειγμα, ένα command για δημιουργία χρήστη:

public sealed record CreateUserCommand(
string Email);

Και ένας handler:

public sealed class CreateUserHandler
{
private readonly IUserRepository _repository;

public CreateUserHandler(IUserRepository repository)
{
    _repository = repository;
}

public async Task<Result<Guid>> Handle(
    CreateUserCommand command,
    CancellationToken cancellationToken)
{
    var exists = await _repository.ExistsByEmailAsync(
        command.Email,
        cancellationToken);

    if (exists)
    {
        return Result.Failure<Guid>(
            UserErrors.EmailAlreadyExists);
    }

    var user = User.Create(command.Email);

    await _repository.AddAsync(
        user,
        cancellationToken);

    return Result.Success(user.Id);
}

}

Ο handler επιστρέφει ένα Result.

Δεν επιστρέφει IActionResult.

Δεν γνωρίζει HTTP status codes.

Επομένως, ο ίδιος handler μπορεί να χρησιμοποιηθεί από ένα Web API, ένα background job ή έναν message consumer.

Το Result Pattern κάνει το συμβόλαιο του use case ανεξάρτητο από το transport mechanism.

Συνδυάζοντας πολλαπλά Results

Σε πιο σύνθετα workflows, μπορεί να χρειαστεί να εκτελέσουμε διαδοχικές λειτουργίες.

Για παράδειγμα:

Εντοπισμός χρήστη.

Έλεγχος δικαιωμάτων.

Δημιουργία παραγγελίας.

Αποθήκευση παραγγελίας.

Κάθε βήμα μπορεί να επιστρέφει Result.

Μια απλή υλοποίηση θα μπορούσε να είναι:

public async Task> CreateOrderAsync(
Guid userId,
CancellationToken cancellationToken)
{
var userResult = await GetUserAsync(
userId,
cancellationToken);

if (userResult.IsFailure)
{
    return Result.Failure<Guid>(
        userResult.Error!);
}

var permissionResult = await CheckPermissionAsync(
    userResult.Value,
    cancellationToken);

if (permissionResult.IsFailure)
{
    return Result.Failure<Guid>(
        permissionResult.Error!);
}

var order = new Order(userId);

await _orderRepository.AddAsync(
    order,
    cancellationToken);

return Result.Success(order.Id);

}

Ο κώδικας είναι σαφής, αλλά σε μεγάλα workflows μπορεί να εμφανιστεί αρκετό επαναλαμβανόμενο error handling.

Εδώ μπορούν να βοηθήσουν functional composition τεχνικές όπως Bind και Map.

10.1 Map

Το Map μετασχηματίζει την τιμή ενός επιτυχημένου Result.

Αν το Result είναι αποτυχημένο, διατηρεί το error.

public static Result Map(
this Result result,
Func mapper)
{
if (result.IsFailure)
{
return Result.Failure(
result.Error!);
}

return Result.Success(
    mapper(result.Value));

}

Παράδειγμα:

Result userResult = GetUser();

Result emailResult = userResult.Map(
user => user.Email);

Αν ο χρήστης βρέθηκε, το αποτέλεσμα περιέχει το email.

Αν ο χρήστης δεν βρέθηκε, το αποτέλεσμα διατηρεί το αρχικό error.

10.2 Bind

Το Bind χρησιμοποιείται όταν η επόμενη λειτουργία επιστρέφει και αυτή Result.

public static Result Bind(
this Result result,
Func> binder)
{
if (result.IsFailure)
{
return Result.Failure(
result.Error!);
}

return binder(result.Value);

}

Παράδειγμα:

Result userResult = GetUser();

Result orderResult = userResult.Bind(
user => CreateOrder(user));

Αν το πρώτο Result αποτύχει, η δεύτερη λειτουργία δεν εκτελείται.

Αν το πρώτο Result επιτύχει, η τιμή του περνά στη δεύτερη λειτουργία.

Αυτή η συμπεριφορά επιτρέπει να δημιουργούμε αλυσίδες λειτουργιών χωρίς να επαναλαμβάνουμε συνεχώς τον ίδιο έλεγχο.

Ωστόσο, χρειάζεται προσοχή.

Η υπερβολική χρήση functional abstractions μπορεί να κάνει έναν απλό επιχειρησιακό αλγόριθμο δυσκολότερο στην ανάγνωση.

Η αναγνωσιμότητα πρέπει να παραμένει σημαντικότερη από την προσπάθεια να εξαφανίσουμε κάθε if.

Validation: Fail Fast ή Error Aggregation;

Μέχρι τώρα κάθε Result περιέχει ένα μόνο error.

Αυτό είναι αρκετό για πολλά business rules.

Ωστόσο, υπάρχουν περιπτώσεις όπου θέλουμε να επιστρέψουμε πολλαπλά validation errors.

Για παράδειγμα, σε μια φόρμα εγγραφής μπορεί να υπάρχουν ταυτόχρονα τα εξής προβλήματα:

Το email δεν είναι έγκυρο.

Ο κωδικός είναι πολύ μικρός.

Το όνομα είναι υποχρεωτικό.

Αν επιστρέψουμε μόνο το πρώτο error, ο χρήστης θα χρειαστεί να διορθώνει ένα πρόβλημα κάθε φορά.

Για validation scenarios μπορούμε να επιλέξουμε ένα πιο σύνθετο αποτέλεσμα:

public sealed record ValidationError(
string PropertyName,
string Code,
string Message);

Και να χρησιμοποιήσουμε ένα collection:

public sealed record ValidationFailure(
IReadOnlyList Errors);

Ένα τέτοιο μοντέλο μπορεί να συνδυαστεί με ValidationProblemDetails, ώστε το API να επιστρέφει σφάλματα ανά πεδίο.

Το σημαντικό είναι να διαχωρίσουμε δύο διαφορετικές στρατηγικές.

Fail Fast: Σταματάμε στην πρώτη αποτυχία. Είναι κατάλληλο όταν η συνέχεια της διαδικασίας δεν έχει νόημα χωρίς την επιτυχία του προηγούμενου βήματος.

Error Aggregation: Συγκεντρώνουμε ανεξάρτητα validation errors. Είναι κατάλληλο όταν θέλουμε να ενημερώσουμε τον χρήστη για όλα τα προβλήματα του request.

Δεν χρειάζεται να χρησιμοποιούμε την ίδια στρατηγική σε κάθε σημείο της εφαρμογής.

Πότε χρησιμοποιούμε Exceptions αντί για Result;

Ένα από τα πιο συχνά λάθη είναι η προσπάθεια να μετατρέψουμε κάθε exception σε Result.

Αυτό δεν είναι απαραίτητα σωστό.

Ας εξετάσουμε μερικές περιπτώσεις.

Περίπτωση

Προτεινόμενος χειρισμός

Email ήδη καταχωρημένο

Result

Προϊόν δεν βρέθηκε

Result

Ανεπαρκές υπόλοιπο

Result

Απαγορευμένη αλλαγή κατάστασης

Result

Database connection failure

Exception

Απρόβλεπτο programming bug

Exception

CancellationToken cancellation

Συνήθως propagation της cancellation

Αναμενόμενη απόρριψη πληρωμής

Result

Απρόβλεπτο failure του payment provider

Exception ή ρητά μοντελοποιημένη αποτυχία, ανάλογα με το συμβόλαιο

Η τελευταία περίπτωση είναι ιδιαίτερα ενδιαφέρουσα.

Μια εξωτερική υπηρεσία μπορεί να αποτύχει για διαφορετικούς λόγους.

Μια απόρριψη πληρωμής λόγω ανεπαρκών χρημάτων είναι επιχειρησιακό αποτέλεσμα.

Αντίθετα, ένα network timeout μπορεί να αποτελεί προσωρινό τεχνικό πρόβλημα.

Σε ένα σύστημα με υψηλές απαιτήσεις αξιοπιστίας, ορισμένα infrastructure failures μπορούν επίσης να μοντελοποιηθούν ως Result, ειδικά όταν αποτελούν αναμενόμενο και ανακτήσιμο μέρος του συμβολαίου.

Το κριτήριο δεν είναι απλώς αν το πρόβλημα είναι τεχνικό ή επιχειρησιακό.

Το βασικό ερώτημα είναι:

Πρόκειται για μια αναμενόμενη κατάσταση που ο caller μπορεί και οφείλει να χειριστεί ως μέρος της κανονικής ροής;

Αν ναι, το Result μπορεί να είναι κατάλληλο.

Αν πρόκειται για παραβίαση εσωτερικής υπόθεσης ή μη αναμενόμενο failure, ένα exception συνήθως είναι πιο σωστό.

Global Exception Handling και Result Pattern

Σε μια σωστά σχεδιασμένη εφαρμογή, το Result Pattern και το global exception handling λειτουργούν συμπληρωματικά.

Το Result Pattern χειρίζεται τις αναμενόμενες αποτυχίες.

Το global exception handling αναλαμβάνει τις απροσδόκητες αποτυχίες.

Στο ASP.NET Core μπορούμε να χρησιμοποιήσουμε το IExceptionHandler.

using Microsoft.AspNetCore.Diagnostics;
using Microsoft.AspNetCore.Mvc;

public sealed class GlobalExceptionHandler
: IExceptionHandler
{
private readonly ILogger _logger;

public GlobalExceptionHandler(
    ILogger<GlobalExceptionHandler> logger)
{
    _logger = logger;
}

public async ValueTask<bool> TryHandleAsync(
    HttpContext httpContext,
    Exception exception,
    CancellationToken cancellationToken)
{
    _logger.LogError(
        exception,
        "An unexpected error occurred.");

    var problem = new ProblemDetails
    {
        Status = StatusCodes.Status500InternalServerError,
        Title = "Internal Server Error",
        Detail = "An unexpected error occurred."
    };

    httpContext.Response.StatusCode =
        StatusCodes.Status500InternalServerError;

    await httpContext.Response.WriteAsJsonAsync(
        problem,
        options: null,
        contentType: "application/problem+json",
        cancellationToken: cancellationToken);

    return true;
}

}

Στο Program.cs:

builder.Services.AddProblemDetails();

builder.Services.AddExceptionHandler<
GlobalExceptionHandler>();

var app = builder.Build();

app.UseExceptionHandler();

app.MapControllers();

app.Run();

Η συγκεκριμένη υλοποίηση είναι απλοποιημένη.

Σε production περιβάλλον θα πρέπει να διατηρούμε τη σωστή συμπεριφορά για cancellations, να προσέχουμε αν έχει ήδη ξεκινήσει η HTTP response και να μην αποκαλύπτουμε εσωτερικές πληροφορίες στους clients.

Επίσης, για τα unexpected failures συνήθως θέλουμε structured logging και correlation identifiers.

Το βασικό αρχιτεκτονικό συμπέρασμα παραμένει το ίδιο:

Δεν χρειάζεται να επιλέξουμε ανάμεσα σε Result Pattern και exception handling.

Χρειαζόμαστε και τα δύο, αλλά για διαφορετικές ευθύνες.

Unit Testing με Result Pattern

Ένα σημαντικό πλεονέκτημα του Result Pattern είναι ότι οι αναμενόμενες αποτυχίες μπορούν να ελεγχθούν χωρίς να βασιζόμαστε σε exception assertions.

Ας δούμε ένα παράδειγμα με xUnit και Moq.

[Fact]
public async Task RegisterAsync_ShouldReturnConflict_WhenEmailExists()
{
// Arrange
var repository = new Mock();

repository
    .Setup(x => x.ExistsByEmailAsync(
        It.IsAny<string>(),
        It.IsAny<CancellationToken>()))
    .ReturnsAsync(true);

var service = new UserService(repository.Object);

var request = new RegisterUserRequest(
    "test@example.com");

// Act
var result = await service.RegisterAsync(
    request,
    CancellationToken.None);

// Assert
Assert.True(result.IsFailure);

Assert.Equal(
    "Users.EmailAlreadyExists",
    result.Error!.Code);

Assert.Equal(
    ErrorType.Conflict,
    result.Error.Type);

repository.Verify(
    x => x.AddAsync(
        It.IsAny<User>(),
        It.IsAny<CancellationToken>()),
    Times.Never);

}

Το test ελέγχει όχι μόνο ότι η λειτουργία απέτυχε, αλλά και ότι απέτυχε για τον σωστό λόγο.

Επίσης, επιβεβαιώνει ότι δεν επιχειρήθηκε αποθήκευση χρήστη.

Testing του Success Path

[Fact]
public async Task RegisterAsync_ShouldReturnUser_WhenEmailIsAvailable()
{
// Arrange
var repository = new Mock();

repository
    .Setup(x => x.ExistsByEmailAsync(
        It.IsAny<string>(),
        It.IsAny<CancellationToken>()))
    .ReturnsAsync(false);

var service = new UserService(repository.Object);

var request = new RegisterUserRequest(
    "test@example.com");

// Act
var result = await service.RegisterAsync(
    request,
    CancellationToken.None);

// Assert
Assert.True(result.IsSuccess);

Assert.NotEqual(
    Guid.Empty,
    result.Value.UserId);

Assert.Equal(
    "test@example.com",
    result.Value.Email);

repository.Verify(
    x => x.AddAsync(
        It.IsAny<User>(),
        It.IsAny<CancellationToken>()),
    Times.Once);

}

Με αυτόν τον τρόπο, τα tests περιγράφουν καθαρά το αναμενόμενο συμβόλαιο του use case.

Φυσικά, εξακολουθούμε να χρειαζόμαστε integration tests για πραγματικά database constraints, transaction behavior και HTTP mappings.

Result Pattern και Performance

Ένα επιχείρημα που συχνά αναφέρεται υπέρ του Result Pattern είναι η απόδοση.

Η δημιουργία και το throwing ενός exception έχουν κόστος, ειδικά επειδή περιλαμβάνουν stack trace και μηχανισμό exception propagation.

Αν χρησιμοποιούμε exceptions για συχνές, αναμενόμενες αποτυχίες, αυτό το κόστος μπορεί να γίνει σημαντικό.

Ένα Result αντικείμενο συνήθως έχει πιο προβλέψιμο κόστος.

Ωστόσο, χρειάζεται προσοχή.

Το Result Pattern δεν είναι αυτόματα ταχύτερο σε κάθε σενάριο.

Μια class-based υλοποίηση όπως η δική μας δημιουργεί allocations.

Μια struct-based υλοποίηση μπορεί να μειώσει allocations, αλλά εισάγει άλλες προκλήσεις, όπως default struct states και μεγαλύτερο κόστος αντιγραφής.

Επίσης, αν μια αποτυχία συμβαίνει εξαιρετικά σπάνια, η διαφορά μπορεί να είναι πρακτικά αμελητέα.

Σε εφαρμογές με σημαντικές απαιτήσεις απόδοσης, η σωστή προσέγγιση είναι να χρησιμοποιούμε benchmarks με αντιπροσωπευτικά workloads.

Το βασικό όφελος του Result Pattern είναι πρωτίστως η σαφήνεια του συμβολαίου και η αρχιτεκτονική συνέπεια.

Η απόδοση μπορεί να αποτελέσει επιπλέον πλεονέκτημα, αλλά δεν πρέπει να είναι το μοναδικό κριτήριο επιλογής.

Συνηθισμένα λάθη

16.1 Μετατροπή κάθε exception σε Result

Αν κάθε catch καταλήγει σε Result.Failure, υπάρχει κίνδυνος να κρύβουμε πραγματικά bugs.

Για παράδειγμα:

try
{
await SaveAsync();
}
catch (Exception)
{
return Result.Failure(
Error.Failure(
"General.Error",
"Something went wrong."));
}

Ο κώδικας χάνει σημαντική πληροφορία για την πραγματική αιτία της αποτυχίας.

Η σωστή στρατηγική είναι να μετατρέπουμε σε Result μόνο τις αποτυχίες που γνωρίζουμε πώς να αναγνωρίσουμε και να χειριστούμε.

16.2 Επιστροφή HTTP errors από το Domain

Το domain δεν πρέπει να γνωρίζει ότι ένα error αντιστοιχεί σε HTTP 404 ή HTTP 409.

Το HTTP mapping ανήκει στο presentation layer.

16.3 Χρήση ενός γενικού error για τα πάντα

Αν όλα τα failures επιστρέφουν:

Error.Failure(
"Error",
"Operation failed");

χάνουμε μεγάλο μέρος της αξίας του Result Pattern.

Τα errors πρέπει να έχουν συγκεκριμένη σημασιολογία.

16.4 Υπερβολικά πολύπλοκη υλοποίηση

Δεν χρειάζεται κάθε εφαρμογή δεκάδες extensions, operators και functional abstractions.

Μια μικρή εφαρμογή μπορεί να καλυφθεί από ένα απλό Result και έναν mapper.

Η πολυπλοκότητα πρέπει να προστίθεται όταν υπάρχει πραγματική ανάγκη.

16.5 Αγνόηση των failed Results

Ένα Result μπορεί να επιστραφεί και να αγνοηθεί:

await ProcessOrderAsync(orderId);

Αν η μέθοδος επιστρέφει Task, ο compiler δεν απαιτεί να ελεγχθεί το αποτέλεσμα.

Αυτό σημαίνει ότι το Result Pattern απαιτεί και πειθαρχία από την ομάδα.

Code reviews, conventions και κατάλληλοι analyzers μπορούν να βοηθήσουν στον εντοπισμό τέτοιων περιπτώσεων.

Πότε αξίζει να χρησιμοποιήσουμε το Result Pattern;

Το Result Pattern είναι ιδιαίτερα χρήσιμο όταν:

Έχουμε αρκετούς επιχειρησιακούς κανόνες που μπορούν να οδηγήσουν σε αναμενόμενες αποτυχίες.

Θέλουμε να διαχωρίσουμε την επιχειρησιακή λογική από το HTTP layer.

Χρησιμοποιούμε Clean Architecture ή CQRS.

Θέλουμε συνεπή error contracts.

Χρειαζόμαστε προβλέψιμο error handling ανάμεσα σε διαφορετικά application layers.

Θέλουμε να γράφουμε tests που ελέγχουν ρητά τις διαφορετικές εκβάσεις ενός use case.

Δεν είναι όμως απαραίτητο να χρησιμοποιείται παντού.

Σε μια πολύ απλή εφαρμογή CRUD, με ελάχιστους επιχειρησιακούς κανόνες, μπορεί να εισάγει περισσότερη πολυπλοκότητα από όση αφαιρεί.

Επίσης, δεν χρειάζεται κάθε private helper method να επιστρέφει Result.

Μια συνάρτηση που εκτελεί έναν απλό μαθηματικό υπολογισμό ή έναν εγγυημένα έγκυρο μετασχηματισμό μπορεί να συνεχίσει να επιστρέφει απευθείας την τιμή της.

Το Result Pattern έχει μεγαλύτερη αξία στα σημεία όπου η αποτυχία αποτελεί ουσιαστικό μέρος του συμβολαίου.

Custom Result ή έτοιμη βιβλιοθήκη;

Μέχρι τώρα υλοποιήσαμε μια δική μας έκδοση.

Αυτό είναι ιδιαίτερα χρήσιμο για να κατανοήσουμε τις αρχές του pattern.

Σε πραγματικά projects, όμως, υπάρχουν και ώριμες βιβλιοθήκες που προσφέρουν παρόμοια abstractions.

Ενδεικτικά:

FluentResults

ErrorOr

Ardalis.Result

CSharpFunctionalExtensions

Η επιλογή εξαρτάται από τις ανάγκες της εφαρμογής.

Μια έτοιμη βιβλιοθήκη μπορεί να προσφέρει richer error models, composition operators, validation support και integration helpers.

Από την άλλη πλευρά, ένα μικρό custom implementation μπορεί να είναι ευκολότερο στην κατανόηση και να προσφέρει πλήρη έλεγχο του συμβολαίου.

Δεν υπάρχει μία σωστή επιλογή για όλες τις ομάδες.

Πριν επιλέξουμε βιβλιοθήκη, αξίζει να εξετάσουμε την πολυπλοκότητα του API της, τη συμβατότητα με το architecture μας, τη συντήρηση, τις εξαρτήσεις και το πόσο εύκολα μπορούμε να τη χρησιμοποιήσουμε με συνέπεια.

Τελικές σκέψεις

Το Result Pattern δεν είναι απλώς ένας διαφορετικός τρόπος να επιστρέφουμε errors.

Είναι ένας τρόπος να κάνουμε τα συμβόλαια των λειτουργιών μας πιο ξεκάθαρα.

Αντί μια μέθοδος να φαίνεται ότι επιστρέφει μόνο μια τιμή, ενώ στην πραγματικότητα μπορεί να αποτύχει για πολλούς αναμενόμενους λόγους, επιστρέφει ένα αντικείμενο που αναπαριστά ρητά την επιτυχία ή την αποτυχία.

Αυτό μας επιτρέπει να σχεδιάζουμε εφαρμογές στις οποίες:

Οι επιχειρησιακές αποτυχίες είναι σαφώς ορισμένες.

Τα exceptions διατηρούν τον ρόλο τους για μη αναμενόμενες καταστάσεις.

Το application layer παραμένει ανεξάρτητο από το HTTP.

Οι controllers είναι απλούστεροι.

Τα error contracts είναι πιο συνεπή.

Τα unit tests περιγράφουν καθαρά τις διαφορετικές εκβάσεις.

Ωστόσο, το Result Pattern δεν αντικαθιστά το σωστό domain modeling, το validation, τα database constraints, τα transactions ή το exception handling.

Ούτε αποτελεί λόγο να προσθέτουμε abstractions σε κάθε σημείο της εφαρμογής.

Η αξία του βρίσκεται στη σωστή χρήση του.

Ένας καλός σχεδιασμός δεν προσπαθεί να εξαφανίσει κάθε πιθανότητα αποτυχίας. Προσπαθεί να κάνει τις αναμενόμενες αποτυχίες σαφείς, προβλέψιμες και εύκολες στον χειρισμό.

Και αυτό είναι τελικά το σημαντικότερο που μας προσφέρει το Result Pattern σε μια σύγχρονη εφαρμογή ASP.NET Core.

Πώς λειτουργεί το Authentication με Microsoft Entra ID στο ASP.NET Core

nikosst — Fri, 02 Oct 2026 20:58:16 +0000

Στις σύγχρονες εφαρμογές δεν είναι απαραίτητο η ίδια η εφαρμογή να αποθηκεύει και να διαχειρίζεται τους κωδικούς πρόσβασης των χρηστών. Αντίθετα, μπορούμε να χρησιμοποιήσουμε έναν Identity Provider, όπως το Microsoft Entra ID, ο οποίος αναλαμβάνει να επιβεβαιώσει την ταυτότητα του χρήστη.

Με απλά λόγια, η εφαρμογή μας δεν χρειάζεται να γνωρίζει τον κωδικό του χρήστη. Ρωτά το Entra ID: «Έχεις επιβεβαιώσει ότι αυτός ο χρήστης είναι πράγματι αυτός που δηλώνει ότι είναι;». Εφόσον η απάντηση είναι θετική, η εφαρμογή μπορεί να συνεχίσει.

Authentication και Authorization

Πριν δούμε τη διαδικασία, πρέπει να ξεχωρίσουμε δύο έννοιες.

Authentication σημαίνει «ποιος είσαι;».

Authorization σημαίνει «τι επιτρέπεται να κάνεις;».

Για παράδειγμα, το Entra ID μπορεί να επιβεβαιώσει ότι ο χρήστης είναι ο nikos@company.com. Αυτό είναι authentication. Το αν ο συγκεκριμένος χρήστης μπορεί να διαγράψει έναν πελάτη είναι authorization και αποτελεί ευθύνη της εφαρμογής.

Ο ρόλος του Microsoft Entra ID

Το Entra ID λειτουργεί ως Identity Provider. Η εφαρμογή μας είναι καταχωρημένη στο Entra ID μέσω ενός App Registration.

Στο App Registration υπάρχουν βασικές πληροφορίες όπως το:

Client ID
Tenant ID
Redirect URI

Το Client ID αναγνωρίζει την εφαρμογή. Δεν είναι password ούτε secret.

Μια ASP.NET Core εφαρμογή μπορεί, για παράδειγμα, να έχει configuration όπως:

{
  "AzureAd": {
    "TenantId": "...",
    "ClientId": "..."
  }
}

Με αυτόν τον τρόπο η εφαρμογή γνωρίζει σε ποιο Entra tenant ανήκει και ποια εφαρμογή εκπροσωπεί.

Τι γίνεται όταν ο χρήστης κάνει Login;

Ας υποθέσουμε ότι έχουμε:

[Authorize]
public IActionResult Dashboard()
{
    return View();
}

Ο χρήστης επισκέπτεται το /Dashboard, αλλά δεν έχει κάνει login.

Το ASP.NET Core αντιλαμβάνεται ότι απαιτείται authentication και οδηγεί τον χρήστη στο Microsoft Entra ID.

Η απλοποιημένη ροή είναι:

Browser
   ↓
ASP.NET Core
   ↓
Microsoft Entra ID
   ↓
User Login
   ↓
ASP.NET Core

Ο χρήστης κάνει login στο Entra ID και, ανάλογα με τις ρυθμίσεις του οργανισμού, μπορεί να χρειαστεί password, MFA ή άλλους ελέγχους ασφαλείας.

Σημαντικό είναι ότι ο κωδικός του χρήστη δεν περνάει από τη δική μας εφαρμογή.

Τι επιστρέφει το Entra ID;

Μετά την επιτυχημένη authentication διαδικασία, το Entra ID επιστρέφει πληροφορίες που επιτρέπουν στην εφαρμογή να γνωρίζει την ταυτότητα του χρήστη.

Στο OpenID Connect χρησιμοποιείται το ID Token.

Το ID Token είναι ένα JWT και περιέχει claims, δηλαδή πληροφορίες σχετικά με τον χρήστη.

Για παράδειγμα:

{
  "name": "Nikos Stavropoulos",
  "preferred_username": "nikos@company.com"
}

Η ASP.NET Core εφαρμογή χρησιμοποιεί αυτές τις πληροφορίες για να δημιουργήσει το authenticated user.

Πού βρίσκεται το OpenID Connect;

Για να καταλάβουμε πώς λειτουργεί το authentication με το Microsoft Entra ID, πρέπει πρώτα να γνωρίζουμε ότι το Entra ID δεν χρησιμοποιεί έναν δικό του, απομονωμένο μηχανισμό επικοινωνίας με κάθε εφαρμογή. Βασίζεται σε διεθνή πρωτόκολλα, κυρίως το OAuth 2.0 και το OpenID Connect (OIDC).

Το OAuth 2.0 αφορά κυρίως το authorization, δηλαδή την πρόσβαση μιας εφαρμογής σε έναν προστατευμένο πόρο. Το OpenID Connect επεκτείνει το OAuth 2.0 και προσθέτει τη δυνατότητα του authentication, δηλαδή την επιβεβαίωση της ταυτότητας του χρήστη.

Μπορούμε επομένως να το δούμε απλά ως εξής:

             Microsoft Entra ID
                    │
                    │ χρησιμοποιεί
                    ▼
           ┌───────────────────┐
           │    OAuth 2.0      │
           │  Authorization    │
           └─────────┬─────────┘
                     │
                     │ επεκτείνεται από
                     ▼
           ┌───────────────────┐
           │ OpenID Connect    │
           │  Authentication   │
           └───────────────────┘

Άρα, όταν ένας χρήστης κάνει login σε μια ASP.NET Core εφαρμογή μέσω Entra ID, το OpenID Connect είναι το πρωτόκολλο που χρησιμοποιείται για να μεταφερθεί στην εφαρμογή η πληροφορία ότι ο χρήστης ταυτοποιήθηκε επιτυχώς.

Τι συμβαίνει στην πράξη;

Η εφαρμογή μας ζητά από το Entra ID να κάνει authentication για τον χρήστη.

Η ροή είναι περίπου:

Browser
│
│ Login
▼
ASP.NET Core Application
│
│ Authentication request
▼
Microsoft Entra ID
│
│ OpenID Connect
│
│ User authenticates
▼
Microsoft Entra ID
│
│ Authentication result
▼
ASP.NET Core Application

Το Entra ID, αφού ολοκληρώσει την ταυτοποίηση, επιστρέφει τα απαραίτητα tokens. Στο OpenID Connect το σημαντικό token για την ταυτότητα του χρήστη είναι το ID Token.

Το ID Token περιέχει claims, δηλαδή πληροφορίες που περιγράφουν την ταυτότητα του χρήστη, όπως το όνομα ή το username.

Επομένως η σχέση είναι:

OpenID Connect
│
▼
Authentication
│
▼
ID Token
│
▼
ASP.NET Core
│
▼
ClaimsPrincipal
│
▼
HttpContext.User

Από την άλλη πλευρά, όταν η εφαρμογή χρειάζεται να αποκτήσει πρόσβαση σε ένα προστατευμένο API, τότε μπαίνει στο παιχνίδι το OAuth 2.0 authorization και χρησιμοποιείται ένα Access Token.

OAuth 2.0
│
▼
Authorization
│
▼
Access Token
│
▼
Protected API

Άρα δεν πρέπει να βλέπουμε το OpenID Connect ως ένα ακόμη framework που προσθέτουμε στην εφαρμογή. Είναι το πρωτόκολλο authentication που χρησιμοποιείται από το Microsoft identity platform για να επιβεβαιωθεί η ταυτότητα του χρήστη.

Στο ASP.NET Core, ο developer συνήθως δεν υλοποιεί χειροκίνητα το OpenID Connect. Η σύνδεση με το Entra ID γίνεται μέσω των authentication libraries και, για εφαρμογές ASP.NET Core, μπορεί να χρησιμοποιηθεί το Microsoft.Identity.Web, το οποίο αναλαμβάνει μεγάλο μέρος της απαιτούμενης integration.

Τι γίνεται μέσα στο ASP.NET Core;

Εδώ βρίσκεται το σημαντικό σημείο για έναν .NET developer.

Το authentication middleware επεξεργάζεται το αποτέλεσμα του authentication και δημιουργεί ένα:

ClaimsPrincipal

Αυτό είναι που τελικά βλέπει η εφαρμογή μέσω:

HttpContext.User

Για παράδειγμα:

User.Identity?.IsAuthenticated

μπορεί να επιστρέψει:

true

και μπορούμε να διαβάσουμε τα claims:

User.Claims

Άρα η διαδικασία είναι:

Microsoft Entra ID
        ↓
      Token
        ↓
ASP.NET Core Authentication
        ↓
   ClaimsPrincipal
        ↓
   HttpContext.User

Και τι κάνει το `[Authorize]`;

Το [Authorize] δεν κάνει authentication από μόνο του. Λέει στο ASP.NET Core ότι το συγκεκριμένο endpoint απαιτεί authenticated user.

Για παράδειγμα:

[Authorize]
public IActionResult Dashboard()
{
    return View();
}

Αν ο χρήστης είναι authenticated, μπορεί να συνεχίσει.

Αν δεν είναι authenticated, ενεργοποιείται η διαδικασία login.

Μπορούμε επίσης να έχουμε authorization με roles ή policies:

[Authorize(Roles = "Admin")]
public IActionResult DeleteUser()
{
    ...
}

Εδώ πλέον δεν μας ενδιαφέρει μόνο αν ο χρήστης είναι authenticated. Θέλουμε να έχει και τον κατάλληλο ρόλο.

ID Token και Access Token

Εδώ υπάρχει μια πολύ σημαντική διάκριση.

Το ID Token χρησιμοποιείται κυρίως για να πληροφορήσει την εφαρμογή σχετικά με την ταυτότητα του χρήστη.

Το Access Token χρησιμοποιείται όταν μια εφαρμογή θέλει να καλέσει ένα προστατευμένο API.

Για παράδειγμα:

User
 ↓
Web Application
 ↓
Orders API

Η Web Application μπορεί να χρειαστεί ένα Access Token για να καλέσει το Orders API.

Το API ελέγχει το token και αποφασίζει αν ο caller έχει την απαιτούμενη πρόσβαση.

Επομένως:

ID Token    → Ποιος είναι ο χρήστης;
Access Token → Τι επιτρέπεται να χρησιμοποιήσει;

Πού βρίσκεται το Microsoft.Identity.Web;

Στο ASP.NET Core δεν χρειάζεται να υλοποιήσουμε μόνοι μας όλη αυτή τη διαδικασία.

Η Microsoft παρέχει το Microsoft.Identity.Web, το οποίο διευκολύνει την ενσωμάτωση του Microsoft Entra ID σε ASP.NET Core εφαρμογές.

Ενδεικτικά:

builder.Services
    .AddAuthentication()
    .AddMicrosoftIdentityWebApp(
        builder.Configuration.GetSection("AzureAd"));

Η βιβλιοθήκη αναλαμβάνει μεγάλο μέρος της integration διαδικασίας με το Microsoft identity platform.

Σε ένα Web API χρησιμοποιούμε αντίστοιχα το κατάλληλο Microsoft Identity Web API integration.

Η συνολική εικόνα

Τελικά, η διαδικασία μπορεί να αποτυπωθεί πολύ απλά:

              Microsoft Entra ID
                     │
                     │ Login
                     ▼
                  User
                     │
                     │ Token
                     ▼
              ASP.NET Core
                     │
                     ▼
              Authentication
                     │
                     ▼
             ClaimsPrincipal
                     │
                     ▼
              Authorization
                     │
                     ▼
                Controller

Το βασικό που πρέπει να καταλάβουμε είναι ότι το Entra ID αναλαμβάνει την ταυτοποίηση, ενώ η εφαρμογή μας χρησιμοποιεί την ταυτότητα που προκύπτει για να εφαρμόσει τους δικούς της κανόνες πρόσβασης.

Αυτός ο διαχωρισμός είναι ιδιαίτερα σημαντικός στις enterprise εφαρμογές. Η εφαρμογή δεν χρειάζεται να διαχειρίζεται passwords και authentication μηχανισμούς από την αρχή. Αντίθετα, βασίζεται σε έναν κεντρικό Identity Provider και επικεντρώνεται στο authorization και στους business κανόνες της.

Με αυτόν τον τρόπο το authentication γίνεται ένα ξεχωριστό κομμάτι της αρχιτεκτονικής και μπορεί να χρησιμοποιηθεί με συνέπεια σε πολλές εφαρμογές και APIs.

Κατανοώντας τα .NET Assemblies στην Clean Architecture: Από τα Compilation Boundaries στα Architecture Tests

nikosst — Mon, 24 Aug 2026 10:16:10 +0000

Όταν συζητάμε για Clean Architecture στο .NET, η προσοχή συνήθως στρέφεται σε έννοιες όπως το Domain Layer, το Application Layer, το Infrastructure Layer, το Dependency Inversion Principle, τα repositories και τα use cases.

Όλες αυτές οι έννοιες είναι θεμελιώδεις. Ωστόσο, πίσω από αυτές υπάρχει ένας μηχανισμός του .NET που δίνει στις αρχιτεκτονικές μας αποφάσεις μια πραγματική τεχνική υπόσταση: το Assembly.

Η κατανόηση ενός assembly δεν περιορίζεται στο ότι «το build παράγει ένα .dll αρχείο». Σε μία σωστά σχεδιασμένη εφαρμογή, ένα assembly μπορεί να αποτελέσει ένα πραγματικό architectural boundary, ένα όριο μεταγλώττισης που διαχωρίζει διαφορετικές ευθύνες του συστήματος.

Από τη στιγμή που αντιληφθούμε αυτή τη σχέση, τα Architecture Tests αποκτούν πολύ μεγαλύτερη σημασία. Δεν αποτελούν απλώς tests που ελέγχουν naming conventions ή namespaces. Μπορούν να επαληθεύσουν ότι η πραγματική, compiled δομή του συστήματος εξακολουθεί να ακολουθεί το dependency graph που σχεδιάσαμε.

Σε αυτό το άρθρο θα εξετάσουμε τη σχέση μεταξύ Projects, Assemblies, Reflection, Clean Architecture και Architecture Tests, χρησιμοποιώντας ως παράδειγμα μία εφαρμογή ASP.NET Core.

Από τον C# κώδικα στο Assembly

Ας θεωρήσουμε μία τυπική λύση Clean Architecture:

TestMyApp

TestMyApp.Domain
TestMyApp.Application
TestMyApp.Infrastructure
TestMyApp.Api

Μέσα στο Visual Studio βλέπουμε τέσσερα διαφορετικά projects.

Σε πρώτη ανάγνωση θα μπορούσε κανείς να θεωρήσει ότι πρόκειται απλώς για έναν τρόπο καλύτερης οργάνωσης του source code.

Η πραγματικότητα όμως είναι βαθύτερη.

Όταν πραγματοποιούμε build τη solution, κάθε project μεταγλωττίζεται και παράγει συνήθως το δικό του assembly.

Για παράδειγμα:

TestMyApp.Domain
│
│ Build
▼
TestMyApp.Domain.dll

Αντίστοιχα:

TestMyApp.Application
│
│ Build
▼
TestMyApp.Application.dll

και:

TestMyApp.Infrastructure
│
│ Build
▼
TestMyApp.Infrastructure.dll

Επομένως, το assembly δεν αποτελεί απλώς μία σύμβαση οργάνωσης που εισάγει το Visual Studio.

Είναι ένα πραγματικό compilation artifact.

Σε υψηλό επίπεδο, η διαδικασία μπορεί να απεικονιστεί ως:

C# Source Code --> C# Compiler

      Assembly 
         IL  
      Metadata
        Types 
       Members
      Assembly 
     References 
         │ 
         ▼ 
   .NET Runtime

Ένα .NET assembly περιλαμβάνει compiled Intermediate Language, metadata για τους τύπους που περιέχει, πληροφορίες σχετικά με το ίδιο το assembly και references προς άλλα assemblies.

Αυτό ακριβώς το χαρακτηριστικό είναι που το κάνει ιδιαίτερα σημαντικό από αρχιτεκτονικής πλευράς.

Assembly και Namespace δεν είναι το ίδιο πράγμα

Ένα από τα σημεία που δημιουργούν συχνά σύγχυση είναι η διαφορά μεταξύ namespace και assembly.

Ας υποθέσουμε ότι το Domain project έχει την ακόλουθη δομή:

Οι παραπάνω classes μπορεί να ανήκουν στα namespaces:

TestMyApp.Domain.Users
TestMyApp.Domain.Orders
TestMyApp.Domain.Products

Όμως όλες μπορούν να βρίσκονται μέσα στο ίδιο assembly:

TestMyApp.Domain.dll

Το namespace αποτελεί κυρίως έναν λογικό μηχανισμό ονομασίας και οργάνωσης των types.

Το assembly, αντίθετα, αποτελεί πραγματική μονάδα compilation και deployment του .NET.

Η διαφορά αυτή έχει ιδιαίτερη αρχιτεκτονική σημασία.

Θα μπορούσαμε να έχουμε ένα μόνο project:

και να ισχυριστούμε ότι έχουμε Clean Architecture επειδή δημιουργήσαμε τέσσερα folders.

Ωστόσο, μετά το build θα μπορούσαμε να καταλήξουμε σε:

MyApplication.dll

Όλα τα layers θα βρίσκονταν μέσα στο ίδιο assembly.

Τα directories θα μας έδιναν λογική οργάνωση, αλλά όχι πραγματικά compilation boundaries.

Αντίθετα, όταν δημιουργούμε:

Domain.csproj
Application.csproj
Infrastructure.csproj
Api.csproj

δημιουργούμε ξεχωριστές μονάδες compilation.

Μετά το build έχουμε:

Domain.dll
Application.dll
Infrastructure.dll
Api.dll

Επομένως, η αρχιτεκτονική παύει να αποτελεί απλώς μία οργάνωση directories και αρχίζει να αποτυπώνεται στην πραγματική compiled δομή του συστήματος.

Το Assembly ως Architectural Boundary

Μία από τις σημαντικότερες αρχές της Clean Architecture αφορά την κατεύθυνση των dependencies.

Σε μία απλοποιημένη μορφή μπορούμε να έχουμε:

API
│
▼
Infrastructure
│
▼
Application
│
▼
Domain

Η ουσία δεν βρίσκεται απλώς στο ότι έχουμε τέσσερα κουτιά.

Η ουσία βρίσκεται στο ποιος επιτρέπεται να γνωρίζει ποιον.

Το Domain αποτελεί τον πυρήνα της εφαρμογής.

Δεν θα πρέπει να γνωρίζει πώς αποθηκεύονται τα δεδομένα.

Δεν θα πρέπει να γνωρίζει τι είναι HTTP request.

Δεν θα πρέπει να γνωρίζει τι είναι ASP.NET Core Controller.

Δεν θα πρέπει να γνωρίζει τι είναι Microsoft Entra ID.

Δεν θα πρέπει να γνωρίζει τι είναι Entity Framework Core.

Ένα Domain Entity θα πρέπει να μπορεί να είναι κάτι τόσο καθαρό όσο:

public class Order 
{ 
  public Guid Id { get; private set; } 
  public decimal Total { get; private set; } 
  public void Confirm() { // Business rule } 
}

Δεν θα θέλαμε μέσα στο Domain να εμφανίζονται dependencies όπως:

Microsoft.AspNetCore.*
Microsoft.EntityFrameworkCore.*
Microsoft.Identity.*

Αυτό σημαίνει ότι αρχιτεκτονικά θέλουμε:

Domain X ───> Infrastructure
Domain X ───> API

Το Domain δεν πρέπει να εξαρτάται από αυτά.

Όταν κάθε layer βρίσκεται σε διαφορετικό project, αυτή η αρχιτεκτονική αρχίζει να αποκτά φυσική υπόσταση μέσα από τα assemblies.

Project References και Assembly Dependencies

Ας υποθέσουμε ότι στο Visual Studio προσθέτουμε:

Application
│
▼
Domain

ως Project Reference.

Αυτό δεν είναι απλώς μία ρύθμιση του Visual Studio.

Δηλώνουμε ότι το Application έχει δικαίωμα να χρησιμοποιεί types του Domain.

Μετά το compilation, η σχέση αυτή αποτυπώνεται στα assemblies:

Application.dll
│
▼
Domain.dll

Έτσι το Application μπορεί να χρησιμοποιήσει:

using TestMyApp.Domain.Users;

και στη συνέχεια:

public class CreateUserHandler 
{ 
  public User Handle() { // ... } 
}

Η αντίστροφη σχέση όμως δεν πρέπει να υπάρχει.

Δεν θέλουμε το Domain να περιέχει:

using TestMyApp.Application;

Η κατεύθυνση:

Application → Domain

είναι επιτρεπτή.

Η κατεύθυνση:

Domain → Application

παραβιάζει το dependency direction που έχουμε επιλέξει.

Εδώ γίνεται εμφανής μία σημαντική αρχή:

Ένα Project Reference δεν είναι απλώς configuration του IDE. Συμμετέχει άμεσα στη dependency topology του compiled συστήματος.

Τι περιέχει ένα Assembly;

Ένα assembly δεν περιέχει απλώς τον C# source code όπως τον γράψαμε.

Σε υψηλό επίπεδο μπορούμε να το αντιληφθούμε ως:

TestMyApp.Domain.dll

Intermediate Language
Metadata
Types
User

Order

Role

Permission

Members
Methods
Properties
Fields

Assembly References

Τα metadata είναι εξαιρετικά σημαντικά.

Επιτρέπουν στο .NET Runtime αλλά και στον δικό μας κώδικα να ανακαλύψει πληροφορίες σχετικά με τη compiled εφαρμογή.

Αυτό μας οδηγεί σε μία από τις σημαντικότερες δυνατότητες του .NET: το Reflection.

Reflection: Παρατηρώντας τη δομή της εφαρμογής

Ας θεωρήσουμε ότι έχουμε:

public class User { }

Μπορούμε να γράψουμε:

var type = typeof(User);

Το typeof(User) δεν δημιουργεί ένα User object.

Δεν είναι:

new User();

Αντίθετα, ζητάμε από το .NET πληροφορίες σχετικά με τον type User.

Μπορούμε για παράδειγμα να εξετάσουμε:

type.Name

ή:

type.Namespace

ή ακόμη πιο ενδιαφέρον:

type.Assembly

Άρα:

var assembly = typeof(User).Assembly;

σημαίνει ουσιαστικά:

Σε ποιο assembly βρίσκεται ο συγκεκριμένος type;

Αν ο User βρίσκεται στο Domain project, τότε το αποτέλεσμα αντιστοιχεί στο:

TestMyApp.Domain.dll

Έτσι δημιουργείται μία πολύ ενδιαφέρουσα σύνδεση:

Type
│
▼
Reflection
│
▼
Assembly
│
▼
Compiled Architecture

Μπορούμε πλέον να εξετάσουμε προγραμματιστικά τη δομή της εφαρμογής μας.

Το AssemblyReference Pattern

Αν θέλουμε να πάρουμε το Domain assembly, θα μπορούσαμε να χρησιμοποιήσουμε:

typeof(User).Assembly

Τεχνικά αυτό λειτουργεί.

Δεν είναι όμως η καλύτερη δυνατή επιλογή.

Ο User αποτελεί business concept.

Μπορεί κάποια στιγμή να μετονομαστεί, να μετακινηθεί ή ακόμη και να αφαιρεθεί.

Για αυτό χρησιμοποιείται συχνά ένα απλό marker type:

namespace TestMyApp.Domain;

public sealed class AssemblyReference { }

Η συγκεκριμένη class φαίνεται αρχικά περίεργη.

Δεν έχει properties.

Δεν έχει methods.

Δεν έχει business logic.

Δεν προορίζεται για:

new AssemblyReference();

Ο ρόλος της είναι διαφορετικός.

Αποτελεί ένα σταθερό σημείο αναφοράς προς το assembly.

Έτσι μπορούμε να γράψουμε:

var assembly = typeof(AssemblyReference).Assembly;

Η λογική είναι:

AssemblyReference
│
│ βρίσκεται στο
▼
Domain Project
│
│ γίνεται compile σε
▼
TestMyApp.Domain.dll

Άρα:

typeof(AssemblyReference).Assembly

μας δίνει με σαφή και type-safe τρόπο το Domain assembly.

Η συγκεκριμένη class δεν μοντελοποιεί κάποιο business concept.

Αποτελεί έναν architectural marker.

Γιατί να μην χρησιμοποιήσουμε απλώς ένα string;

Θα μπορούσαμε θεωρητικά να προσπαθήσουμε να φορτώσουμε:

"TestMyApp.Domain"

μέσω Reflection APIs.

Ωστόσο, η χρήση:

typeof(AssemblyReference).Assembly

είναι ιδιαίτερα απλή και ασφαλής.

Δεν βασιζόμαστε σε κάποιο αυθαίρετο business type και δεν χρειάζεται να διαχειριστούμε χειροκίνητα assembly names.

Το ίδιο pattern μπορεί να χρησιμοποιηθεί σε όλα τα layers:

Domain
└── AssemblyReference.cs

Application
└── AssemblyReference.cs

Infrastructure
└── AssemblyReference.cs

Api
└── AssemblyReference.cs

Έτσι κάθε assembly αποκτά ένα σαφές entry point για reflection-based operations.

Από την αρχιτεκτονική σύμβαση στο Architecture Test

Ας υποθέσουμε ότι έχουμε αποφασίσει:

Το Domain δεν επιτρέπεται να εξαρτάται από Application, Infrastructure ή API.

Το να γράψουμε αυτή την πρόταση σε ένα README είναι χρήσιμο.

Το να τη σχεδιάσουμε σε ένα architecture diagram είναι επίσης χρήσιμο.

Όμως τίποτα από αυτά δεν εμποδίζει έναν developer να παραβιάσει τον κανόνα έξι μήνες αργότερα.

Για παράδειγμα, κάποιος μπορεί να εισαγάγει στο Domain μία εξάρτηση προς Infrastructure.

Η εφαρμογή μπορεί να συνεχίσει να λειτουργεί.

Τα business unit tests μπορεί να συνεχίσουν να περνούν.

Το API μπορεί να επιστρέφει κανονικά 200 OK.

Παρόλα αυτά, η αρχιτεκτονική έχει υποβαθμιστεί.

Αυτό μας οδηγεί στη διάκριση μεταξύ δύο διαφορετικών μορφών correctness:

Behavioural Correctness
και
Structural Correctness

Ένα κλασικό Unit Test εξετάζει συνήθως:

Για συγκεκριμένο input,
παράγει η μέθοδος το σωστό output;

Ένα Architecture Test εξετάζει κάτι διαφορετικό:

Η compiled δομή του συστήματος
εξακολουθεί να ακολουθεί
τους αρχιτεκτονικούς κανόνες;

Architecture Testing με NetArchTest

Ένα χαρακτηριστικό architecture test μπορεί να είναι:

`using NetArchTest.Rules;
using TestMyApp.Domain;

namespace TestMyApp.ArchitectureTests;

public class DomainArchitectureTests
{
[Fact]
public void Domain_Should_Not_Have_Dependency_On_Other_Layers()
{
var assembly = typeof(AssemblyReference).Assembly;

    var result = Types
        .InAssembly(assembly)
        .ShouldNot()
        .HaveDependencyOnAny(
            "TestAILoginAuthoAuthed.Application",
            "TestAILoginAuthoAuthed.Infrastructure",
            "TestAILoginAuthoAuthed.Api")
        .GetResult();

    Assert.True(result.IsSuccessful);
}

Παρότι πρόκειται για ελάχιστο κώδικα, το test εκφράζει μία σημαντική αρχιτεκτονική πολιτική.

Ας εξετάσουμε τι πραγματικά συμβαίνει.

Αρχικά:

var assembly = typeof(AssemblyReference).Assembly;

εντοπίζουμε το Domain assembly.

Στη συνέχεια:

Types.InAssembly(assembly)

ζητάμε από το NetArchTest να εξετάσει τους types που υπάρχουν μέσα στο συγκεκριμένο assembly.

Εννοιολογικά:

TestMyApp.Domain.dll
│
▼
Examine Types
│
┌───────┼────────┐
▼ ▼ ▼
User Order Role

Στη συνέχεια:

.ShouldNot()
.HaveDependencyOnAny(...)

εκφράζει τον αρχιτεκτονικό περιορισμό.

Ουσιαστικά το test ρωτά:

Για τους types του Domain assembly:

Υπάρχει dependency προς Application;
Υπάρχει dependency προς Infrastructure;
Υπάρχει dependency προς API?

     │
┌────┴────┐
│         │

ΝΑΙ ΟΧΙ
│ │
▼ ▼
FAIL PASS

Έτσι ένας κανόνας που προηγουμένως υπήρχε μόνο ως αρχιτεκτονική πρόθεση μετατρέπεται σε εκτελέσιμο specification.

Unit Tests και Architecture Tests προστατεύουν διαφορετικά πράγματα

Ας θεωρήσουμε ένα Unit Test:

[Fact] public void Order_Should_Calculate_Total() { // ... }

Το συγκεκριμένο test προστατεύει μία επιχειρησιακή συμπεριφορά.

Θέλουμε να γνωρίζουμε ότι το Order υπολογίζει σωστά το total.

Αντίθετα:

[Fact] public void Domain_Should_Not_Depend_On_Infrastructure() { // ... }

δεν ενδιαφέρεται για το αποτέλεσμα κάποιου business calculation.

Προστατεύει τη δομή του συστήματος.

Έχουμε επομένως:

              Software Correctness
                      │
           ┌──────────┴──────────┐
           │                     │
           ▼                     ▼
   Behavioural Rules       Structural Rules
           │                     │
           ▼                     ▼
      Unit Tests          Architecture Tests

Αυτές οι δύο κατηγορίες tests είναι συμπληρωματικές.

Το γεγονός ότι μία εφαρμογή παράγει σωστά αποτελέσματα δεν σημαίνει ότι διαθέτει σωστή αρχιτεκτονική.

Και αντίστροφα, μία άψογη dependency structure δεν σημαίνει ότι το business logic λειτουργεί σωστά.

Η έννοια του Architectural Fitness Function

Ένας ιδιαίτερα χρήσιμος τρόπος να αντιληφθούμε τα Architecture Tests είναι ως Architectural Fitness Functions.

Κατά τον σχεδιασμό του συστήματος αποφασίζουμε ότι ορισμένες ιδιότητες πρέπει να παραμένουν αληθείς όσο εξελίσσεται η εφαρμογή.

Για παράδειγμα:

Το Domain πρέπει να παραμένει ανεξάρτητο.

Το Application δεν πρέπει να εξαρτάται από Infrastructure.

Οι Controllers δεν πρέπει να χρησιμοποιούν απευθείας DbContext.

Το Domain δεν πρέπει να γνωρίζει το Entity Framework Core.

Το Domain δεν πρέπει να γνωρίζει το ASP.NET Core.

Το persistence implementation πρέπει να παραμένει εκτός Domain.

Τα Architecture Tests μπορούν να αξιολογούν συνεχώς αυτές τις ιδιότητες.

Έτσι μετακινούμαστε από ένα μοντέλο:

Architecture
=
Documentation
+
Developer Discipline

σε ένα ισχυρότερο μοντέλο:

Architecture
=
Documentation
+
Compilation Boundaries
+
Automated Verification

Αυτό είναι ιδιαίτερα σημαντικό σε συστήματα που πρόκειται να συντηρηθούν για χρόνια.

Το πραγματικό νόημα ενός failing Architecture Test

Ένα Architecture Test γίνεται ακόμη πιο κατανοητό όταν το δούμε να αποτυγχάνει.

Ας υποθέσουμε ότι κάποιος δημιουργεί dependency:

Domain
│
└────────────► Infrastructure

ενώ η αρχιτεκτονική απαιτεί:

Domain
X────────────► Infrastructure

Το application μπορεί να εξακολουθεί να κάνει compile.

Ένα endpoint μπορεί να συνεχίζει να επιστρέφει:

200 OK

Όμως το architecture test θα αποτύχει.

Αυτό δεν σημαίνει απαραίτητα ότι έχουμε functional bug.

Σημαίνει ότι έχουμε architectural regression.

Η διάκριση είναι σημαντική.

Ένα failing business test μπορεί να μας πει:

Η εφαρμογή δεν συμπεριφέρεται όπως πρέπει.

Ένα failing architecture test μπορεί να μας πει:

Η εφαρμογή εξακολουθεί ίσως να συμπεριφέρεται σωστά, αλλά η εσωτερική της δομή έχει αρχίσει να αποκλίνει από την αρχιτεκτονική που συμφωνήσαμε.

Σε ένα CI/CD pipeline αυτό είναι εξαιρετικά ισχυρό.

Ένα Pull Request που εισάγει απαγορευμένο dependency μπορεί να αποτύχει πριν γίνει merge.

Η αρχιτεκτονική αποκτά επομένως έναν βαθμό αυτοπροστασίας.

Γιατί έχει μεγαλύτερη σημασία σε μεγάλα συστήματα

Σε μία εφαρμογή δύο χιλιάδων γραμμών κώδικα, ένας developer μπορεί ίσως να γνωρίζει ολόκληρο το dependency graph.

Σε ένα production σύστημα εκατοντάδων χιλιάδων γραμμών αυτό δεν είναι ρεαλιστικό.

Οι ομάδες αλλάζουν.

Νέοι developers προστίθενται.

Τα requirements μεταβάλλονται.

Νέα integrations εμφανίζονται.

Τα deadlines δημιουργούν πίεση.

Το Infrastructure μεγαλώνει.

Χωρίς μηχανισμούς ελέγχου, μία αρχικά καθαρή αρχιτεκτονική μπορεί σταδιακά να μετατραπεί σε:

Domain ─────────► Infrastructure
▲ │
│ ▼
Application ◄──────── API
│ ▲
└───────────────────┘

Το σύστημα μπορεί να εξακολουθεί να λειτουργεί, αλλά η δυνατότητα ανεξάρτητης εξέλιξης των components έχει περιοριστεί σημαντικά.

Αυτό το φαινόμενο συχνά περιγράφεται ως architectural erosion.

Τα compilation boundaries και τα architecture tests δεν εξαφανίζουν το πρόβλημα, αλλά δημιουργούν έναν σημαντικό μηχανισμό αντίστασης απέναντί του.

Τα Assemblies δεν δημιουργούν από μόνα τους Clean Architecture

Υπάρχει, ωστόσο, μία σημαντική παγίδα.

Το γεγονός ότι δημιουργήσαμε:

Domain
Application
Infrastructure
Api

ως τέσσερα διαφορετικά projects δεν σημαίνει αυτομάτως ότι έχουμε Clean Architecture.

Μπορούμε κάλλιστα να δημιουργήσουμε τέσσερα assemblies με λανθασμένα dependencies.

Για παράδειγμα:

Domain ───────► Infrastructure
Application ──► API
Infrastructure ► Application
API ──────────► Domain

Τα projects από μόνα τους δεν λύνουν το πρόβλημα.

Παρέχουν όμως έναν μηχανισμό πάνω στον οποίο μπορούμε να επιβάλουμε πραγματικά boundaries.

Η αρχιτεκτονική απαιτεί πρώτα συνειδητές αποφάσεις σχετικά με τα dependencies.

Στη συνέχεια τα assemblies και τα tests μπορούν να βοηθήσουν στην επιβολή αυτών των αποφάσεων.

Architecture Tests χωρίς αρχιτεκτονικό λόγο είναι απλώς ceremony

Το ίδιο ισχύει και για τα Architecture Tests.

Δεν έχει ιδιαίτερη αξία να δημιουργούμε δεκάδες tests μόνο και μόνο επειδή μπορούμε.

Κάθε architectural rule θα πρέπει να απαντά στην ερώτηση:

Ποια σημαντική ιδιότητα του συστήματος προστατεύει αυτός ο κανόνας;

Για παράδειγμα:

Domain must not depend on Infrastructure

έχει ξεκάθαρη αιτιολόγηση.

Προστατεύει την ανεξαρτησία των business rules από τεχνολογικές λεπτομέρειες.

Αντίθετα, ένας αυθαίρετος κανόνας naming χωρίς πραγματικό architectural impact μπορεί να δημιουργήσει περισσότερο θόρυβο παρά αξία.

Τα Architecture Tests είναι περισσότερο χρήσιμα όταν προστατεύουν:

Dependency Direction
Coupling
Separation of Concerns
Replaceability
Testability
Technology Independence

και όχι όταν χρησιμοποιούνται απλώς ως μηχανισμός επιβολής προσωπικών προτιμήσεων.

Η συνολική σχέση

Μπορούμε πλέον να ενώσουμε όλες τις έννοιες σε μία ακολουθία:

Architectural Decision
│
▼
Project Boundary
│
▼
Compilation Boundary
│
▼
Assembly
│
▼
Assembly Metadata / Types
│
▼
Reflection
│
▼
NetArchTest
│
▼
Automated Architecture Test
│
▼
CI/CD Validation

Αυτή είναι ίσως η σημαντικότερη ιδέα.

Ξεκινάμε από μία αφηρημένη αρχιτεκτονική απόφαση:

Το Domain πρέπει να είναι ανεξάρτητο από το Infrastructure.

Τη μετατρέπουμε σε project boundaries.

Τα projects μετατρέπονται σε assemblies.

Τα assemblies διαθέτουν metadata.

Το Reflection μας επιτρέπει να εξετάσουμε αυτά τα metadata.

Το NetArchTest μπορεί να εφαρμόσει κανόνες πάνω στους types των assemblies.

Το xUnit μπορεί να εκτελέσει αυτούς τους κανόνες ως tests.

Και τελικά ένα CI/CD pipeline μπορεί να εμποδίσει την εισαγωγή ενός architectural regression στην κύρια έκδοση του συστήματος.

Έτσι μία αφηρημένη αρχιτεκτονική αρχή καταλήγει να είναι machine-verifiable.

Να θυμάσαι..

Η κατανόηση των assemblies αλλάζει σημαντικά τον τρόπο με τον οποίο μπορούμε να αντιληφθούμε την Clean Architecture στο .NET.

Η αρχιτεκτονική δεν είναι πλέον απλώς:

Domain
Application
Infrastructure
API

σχεδιασμένη ως τέσσερα κουτιά σε ένα διάγραμμα.

Τα κουτιά αυτά μπορούν να αντιστοιχούν σε πραγματικές compilation units:

Domain.dll
Application.dll
Infrastructure.dll
Api.dll

με σαφείς dependency relationships μεταξύ τους.

Το assembly αποτελεί επομένως κάτι περισσότερο από το αποτέλεσμα του compiler. Σε μία συνειδητά σχεδιασμένη εφαρμογή μπορεί να αποτελέσει τεχνική αναπαράσταση ενός architectural boundary.

Το Reflection μας επιτρέπει να εξετάσουμε αυτή την αναπαράσταση.

Ένας απλός marker type:

public sealed class AssemblyReference
{
}

μας παρέχει ένα σταθερό σημείο πρόσβασης:

typeof(AssemblyReference).Assembly

και από εκεί μπορούμε να εξετάσουμε το compiled Domain:

Assembly
↓
Types
↓
Dependencies
↓
Architectural Rules

Με εργαλεία όπως το NetArchTest μπορούμε στη συνέχεια να μετατρέψουμε μία αρχιτεκτονική αρχή όπως:

Domain must not depend on Infrastructure

σε executable test.

Αυτό αποτελεί μία ουσιαστική μετάβαση από τη documented architecture προς την executable architecture.

Σε ένα ώριμο software system, η αρχιτεκτονική δεν θα πρέπει να εξαρτάται αποκλειστικά από τη μνήμη των developers, από ένα παλιό διάγραμμα ή από την προσοχή του reviewer σε κάθε Pull Request.

Οι σημαντικότεροι κανόνες της μπορούν, όπου αυτό είναι τεχνικά εφικτό και αρχιτεκτονικά χρήσιμο, να αποτελούν μέρος του ίδιου του μηχανισμού επαλήθευσης του συστήματος.

Και εκεί βρίσκεται ίσως η μεγαλύτερη χρησιμότητα των assemblies στο συγκεκριμένο πλαίσιο:

μετατρέπουν τα αρχιτεκτονικά όρια από αφηρημένες γραμμές ενός διαγράμματος σε πραγματικά όρια του compiled software — όρια που μπορούμε να παρατηρήσουμε, να εξετάσουμε και τελικά να ελέγξουμε αυτοματοποιημένα.

Πλήρης αρχιτεκτονική JWT, Middleware, Authorization, Permissions και Cache σε .NET

nikosst — Fri, 12 Jun 2026 13:34:24 +0000

Σε ένα σύγχρονο ASP.NET Core backend, το authentication και το authorization δεν είναι μία ενιαία διαδικασία, ούτε ένα σημείο κώδικα που “ανεβάζεις και τελείωσες”. Είναι μια ροή από στάδια, όπου κάθε στάδιο έχει διαφορετική ευθύνη και κανένα δεν πρέπει να μπερδεύεται με το άλλο.

Όταν αυτά τα στάδια ανακατεύονται, το αποτέλεσμα είναι σύστημα δύσκολο να συντηρηθεί, δύσκολο να επεκταθεί και συνήθως αργό. Όταν όμως είναι σωστά διαχωρισμένα, το σύστημα γίνεται προβλέψιμο, γρήγορο και scalable.

Πώς ενεργοποιείται ο Authorization Handler;

Ίσως αναρωτιέστε πώς καλείται ο AuthorizationHandler, αφού δεν τον καλούμε ποτέ εμείς μέσα από τον Controller.

Η απάντηση είναι ότι αυτό γίνεται αυτόματα από το ASP.NET Core.

Όταν ένα endpoint προστατεύεται με μια πολιτική, για παράδειγμα:

[Authorize(Policy = "Orders.Read")]
public IActionResult GetOrders()
{
    ...
}

το Authorization Middleware εντοπίζει ότι το endpoint απαιτεί την πολιτική Orders.Read. Πριν επιτρέψει την εκτέλεση του Controller, ενεργοποιεί αυτόματα τον αντίστοιχο AuthorizationHandler.

Ο AuthorizationHandler χρησιμοποιεί το PermissionService για να ελέγξει αν ο χρήστης διαθέτει το απαιτούμενο permission. Αν ο έλεγχος είναι επιτυχής, το request συνεχίζει στον Controller. Διαφορετικά επιστρέφεται 403 Forbidden και ο Controller δεν εκτελείται ποτέ.

Το πρώτο σημείο: Middleware και JWT validation

Κάθε request που έρχεται στο API δεν φτάνει ποτέ απευθείας στον controller. Περνάει πρώτα από το middleware pipeline της ASP.NET Core.

Εκεί βρίσκεται το authentication middleware, το οποίο είναι υπεύθυνο να ελέγξει το JWT token πριν συμβεί οτιδήποτε άλλο.

Σε αυτό το σημείο γίνεται ο έλεγχος της υπογραφής του token, του issuer, του audience και κυρίως του χρόνου ζωής του. Αν το token έχει λήξει, το request απορρίπτεται άμεσα και επιστρέφεται 401 Unauthorized χωρίς να εκτελεστεί τίποτα άλλο.

Αυτό σημαίνει πρακτικά ότι ο χρήστης “κόβεται” πριν φτάσει σε business logic, πριν φτάσει σε authorization, πριν γίνει οποιοδήποτε database call. Το middleware λειτουργεί σαν απόλυτο security gate.

Αν το token είναι έγκυρο, τότε δημιουργείται το HttpContext.User και το request συνεχίζει τη διαδρομή του μέσα στο pipeline.

Τι σημαίνει στην πράξη η λήξη του JWT

Η λήξη του JWT δεν είναι κάτι που το χειρίζεται η εφαρμογή ως business logic. Είναι καθαρά security rule.

Όταν ο χρόνος exp περάσει, το middleware απλά απορρίπτει το request. Δεν υπάρχει session, δεν υπάρχει “logout server side”, δεν υπάρχει κάποια επιπλέον διαδικασία. Το token θεωρείται άκυρο και τελείωσε εκεί η διαδρομή.

Ο client είναι αυτός που πρέπει να αντιδράσει σε αυτή την κατάσταση, είτε κάνοντας refresh token call είτε ζητώντας login ξανά.

Μετά το middleware: αρχίζει το authorization

Μόλις το JWT περάσει τον έλεγχο, το σύστημα γνωρίζει πλέον ποιος είναι ο χρήστης. Αυτό όμως δεν σημαίνει ότι ξέρει τι επιτρέπεται να κάνει.

Εδώ ξεκινά το authorization κομμάτι, το οποίο δεν είναι ένα απλό if statement, ούτε ένα δεύτερο middleware που “τρέχει μόνο του”. Είναι ένα policy-based σύστημα που ενεργοποιείται όταν ένα endpoint απαιτεί συγκεκριμένο δικαίωμα.

Για παράδειγμα, όταν ένα endpoint έχει attribute όπως “Orders.Read”, δεν σημαίνει ότι το framework απλά κοιτάει roles. Σημαίνει ότι ενεργοποιείται μια διαδικασία ελέγχου που θα αποφασίσει δυναμικά αν ο συγκεκριμένος χρήστης μπορεί να εκτελέσει αυτή την ενέργεια.

Πώς υλοποιείται στην πράξη το authorization

Στην πράξη, το authorization εκφράζεται μέσω policies και handlers. Το endpoint δηλώνει τι απαιτείται, και ο handler αποφασίζει αν ο χρήστης το πληροί.

Όταν ένα request φτάνει σε ένα endpoint με policy, η ASP.NET ενεργοποιεί τον αντίστοιχο authorization handler. Εκεί γίνεται η πραγματική αξιολόγηση.

Ο handler δεν παίρνει την απόφαση από μόνος του. Ζητάει δεδομένα από ένα service, το PermissionService, το οποίο είναι υπεύθυνο να βρει τα δικαιώματα του χρήστη.

Πού αποθηκεύονται τα permissions

Τα permissions δεν πρέπει να βρίσκονται μέσα στο JWT. Ο λόγος είναι ότι αλλάζουν συχνά, πρέπει να μπορούν να ανακληθούν και δεν πρέπει να “παγώνουν” μέσα σε ένα token.

Αντίθετα, αποθηκεύονται σε βάση δεδομένων σε κανονικό relational μοντέλο.

Υπάρχουν users, roles και permissions. Οι χρήστες συνδέονται με ρόλους και οι ρόλοι συνδέονται με permissions. Έτσι το σύστημα γίνεται δυναμικό και μπορεί να αλλάξει ανά πάσα στιγμή χωρίς να χρειάζεται reissue όλων των tokens.

PermissionService: το σημείο που διαβάζονται τα δικαιώματα

Το PermissionService είναι το μοναδικό κομμάτι της εφαρμογής που γνωρίζει πώς να πάρει τα permissions ενός χρήστη από τη βάση δεδομένων.

Όταν καλείται, κάνει join μεταξύ users, roles και permissions και επιστρέφει τη λίστα των δικαιωμάτων.

Αυτό το κομμάτι είναι business data access layer και όχι security logic. Η απόφαση για το αν επιτρέπεται μια ενέργεια γίνεται αλλού, όχι εδώ.

Cache γιατί υπάρχει και πού μπαίνει

Αν κάθε request χτυπάει τη βάση για permissions, το σύστημα θα αρχίσει πολύ γρήγορα να υποφέρει σε load.

Γι’ αυτό μπαίνει cache.

Η cache δεν αλλάζει τη λογική του συστήματος. Δεν αποφασίζει τίποτα. Απλώς αποθηκεύει προσωρινά το αποτέλεσμα ενός προηγούμενου query ώστε να μην χρειάζεται να επαναληφθεί.

Το PermissionService πρώτα κοιτάει αν υπάρχουν ήδη τα permissions του χρήστη στην cache. Αν υπάρχουν, τα επιστρέφει αμέσως. Αν δεν υπάρχουν, τότε πηγαίνει στη βάση, τα φέρνει και τα αποθηκεύει για επόμενες κλήσεις.

Έτσι το πρώτο request είναι πιο “βαρύ”, αλλά όλα τα επόμενα είναι σχεδόν άμεσα.

Όλη η ροή μαζί

Όταν όλα τα κομμάτια συνδεθούν μεταξύ τους, η ροή του request είναι καθαρή.

Το request έρχεται στο σύστημα και περνάει πρώτα από το middleware. Εκεί γίνεται ο έλεγχος του JWT. Αν το token έχει λήξει, το request σταματάει αμέσως. Αν είναι valid, δημιουργείται το user context και το request συνεχίζει.

Στη συνέχεια ενεργοποιείται το authorization layer, το οποίο βλέπει ότι το συγκεκριμένο endpoint απαιτεί συγκεκριμένα permissions. Ο authorization handler καλείται και ζητάει τα permissions του χρήστη από το PermissionService.

Το PermissionService πρώτα κοιτάει στην cache. Αν τα δεδομένα υπάρχουν εκεί, τα επιστρέφει άμεσα. Αν όχι, κάνει query στη βάση δεδομένων, τα αποθηκεύει στην cache και τα επιστρέφει.

Αν ο χρήστης έχει το απαιτούμενο permission, το request συνεχίζει στον controller και από εκεί μπορεί να καλέσει άλλα microservices ή να εκτελέσει business logic.

Γιατί αυτό δεν γίνεται bottleneck

Το κρίσιμο σημείο είναι το PermissionService και η βάση δεδομένων. Θεωρητικά αυτό θα μπορούσε να γίνει bottleneck, αλλά στην πράξη δεν γίνεται, γιατί σχεδόν ποτέ δεν χτυπάει τη βάση.

Η cache απορροφά τη συντριπτική πλειοψηφία των requests, οπότε η βάση χρησιμοποιείται μόνο σε cache miss ή όταν αλλάξουν τα permissions.

Αυτό σημαίνει ότι το authorization δεν είναι hot path προς τη βάση. Είναι hot path προς τη cache, η οποία είναι εξαιρετικά γρήγορη.

Έτσι το σύστημα παραμένει σταθερό ακόμα και υπό μεγάλο φορτίο.

Τι συμβαίνει όταν λήξει το JWT;

Μέχρι τώρα είδαμε πώς το middleware επικυρώνει το JWT και αποφασίζει αν ο χρήστης έχει πρόσβαση σε έναν πόρο. Τι γίνεται όμως όταν το Access Token λήξει;

Όταν η API λάβει ένα ληγμένο Access Token, η επικύρωση αποτυγχάνει και επιστρέφεται:

401 Unauthorized

Σε αυτό το σημείο ο χρήστης δεν χρειάζεται να συνδεθεί ξανά ούτε να πατήσει κάποιο κουμπί. Ο client (React, Angular, Blazor, Mobile App κ.λπ.) λαμβάνει την απάντηση 401 Unauthorized και χρησιμοποιεί το Refresh Token που έχει αποθηκεύσει για να ζητήσει ένα νέο Access Token από τον Authentication Server.

POST /refresh-token

Η ροή είναι η εξής:

Client
   │
   │ GET /api/orders
   │ Access Token
   ▼
API
   │
   └── 401 Unauthorized
            │
            ▼
Client
   │
   │ POST /refresh-token
   │ Refresh Token
   ▼
Authentication Server
   │
   └── Νέο Access Token
            │
            ▼
Client
   │
   │ Επαναλαμβάνει το αρχικό request
   ▼
API

Είναι σημαντικό να τονίσουμε ότι η API και το JWT Middleware δεν ανανεώνουν ποτέ το Access Token. Ο μοναδικός τους ρόλος είναι να ελέγχουν αν το token που έλαβαν είναι έγκυρο. Η ανανέωση πραγματοποιείται αποκλειστικά από τον Authentication Server μέσω του Refresh Token, ενώ ο client είναι υπεύθυνος να ξεκινήσει αυτή τη διαδικασία όταν χρειαστεί.

Σημείωση: Αν έχει λήξει ή έχει ανακληθεί και το Refresh Token, τότε ο Authentication Server δεν μπορεί να εκδώσει νέο Access Token. Σε αυτή την περίπτωση ο χρήστης πρέπει να πραγματοποιήσει ξανά login.

Διάγραμμα

┌───────────────────────────────────────────────────────────┐
│                       Client / SPA                        │
└───────────────────────┬───────────────────────────────────┘
                        │
                        ▼
┌───────────────────────────────────────────────────────────┐
│                     HTTP Request                          │
│                  Authorization: Bearer JWT                │
└───────────────────────┬───────────────────────────────────┘
                        │
                        ▼
┌───────────────────────────────────────────────────────────┐
│                 Authentication Middleware                 │
│                                                           │
│  Validate JWT Signature                                   │
│  Validate Issuer / Audience                               │
│  Validate Expiration (exp)                                │
└───────────────────────┬───────────────────────────────────┘
                        │
          ┌─────────────┴─────────────┐
          │                           │
          ▼                           ▼
     Token Invalid               Token Valid
          │                           │
          ▼                           ▼
   401 Unauthorized          HttpContext.User Created
          │                           │
          │                           ▼
          │             ┌──────────────────────────────┐
          │             │    Token Revocation Check    │
          │             │                              │
          │             │ Redis / Cache / DB Lookup    │
          │             └──────────────┬───────────────┘
          │                            │
          │              ┌─────────────┴────────────┐
          │              │                          │
          │              ▼                          ▼
          │        Revoked                    Active
          │              │                          │
          │              ▼                          ▼
          │       401 Unauthorized        Authorization Layer
          │                                         │
          │                                         ▼
          │                     ┌────────────────────────────┐
          │                     │    Policy / Handler        │
          │                     │  Orders.Read Permission    │
          │                     └─────────────┬──────────────┘
          │                                   │
          │                                   ▼
          │                     ┌────────────────────────────┐
          │                     │     PermissionService      │
          │                     └─────────────┬──────────────┘
          │                                   │
          │                                   ▼
          │                     ┌────────────────────────────┐
          │                     │         Cache              │
          │                     │ (MemoryCache / Redis)      │
          │                     └─────────────┬──────────────┘
          │                                   │
          │                 ┌─────────────────┴────────────┐
          │                 │                              │
          │                 ▼                              ▼
          │           Cache Hit                      Cache Miss
          │                 │                              │
          │                 │                              ▼
          │                 │              ┌────────────────────────┐
          │                 │              │      Database          │
          │                 │              │ Users / Roles / Perms  │
          │                 │              └───────────┬────────────┘
          │                 │                          │
          │                 └──────────────┬───────────┘
          │                                │
          │                                ▼
          │                    Permission Decision
          │                                │
          │                    ┌───────────┴───────────┐
          │                    │                       │
          │                    ▼                       ▼
          │                 Allow                   Deny
          │                    │                       │
          │                    ▼                       ▼
          │             Controller              403 Forbidden
          │                    │
          │                    ▼
          │        Orders API / Customers API
          │
          │
          └─────────────────────────────────────────────────


              ACCESS TOKEN EXPIRES
                        │
                        ▼
                Client receives 401
                        │
                        ▼
                POST /auth/refresh
                        │
                        ▼
              Refresh Token Validation
                        │
                        ▼
                Refresh Token Store
                  (DB / Redis)
                        │
          ┌─────────────┴─────────────┐
          │                           │
          ▼                           ▼
      Invalid                    Valid
          │                           │
          ▼                           ▼
   Login Required          New JWT Issued
                                   │
                                   ▼
                          User Continues

Να θυμάσαι!

Ένα σωστό authentication και authorization σύστημα δεν βασίζεται σε ένα μόνο layer, αλλά σε καθαρό διαχωρισμό ευθυνών.

Το middleware είναι το security gate που απορρίπτει invalid tokens πριν μπουν στο σύστημα.

Το authorization layer είναι το σημείο που αποφασίζει αν ένας χρήστης έχει πρόσβαση σε ένα συγκεκριμένο endpoint.

Το PermissionService είναι το σημείο που διαβάζει την πραγματική κατάσταση από τη βάση δεδομένων.

Και η cache είναι απλώς ένα performance layer που μειώνει το load χωρίς να επηρεάζει τη λογική του συστήματος.

Όταν όλα αυτά λειτουργούν μαζί με καθαρό διαχωρισμό, έχεις ένα σύστημα που είναι ταυτόχρονα ασφαλές, γρήγορο και έτοιμο για production scale χωρίς bottlenecks.

nikosstit@gmail.com

AI Development Tools για Σύγχρονους Software Engineers: Πότε να χρησιμοποιείς Agent, Ask, Plan, GitHub Copilot, Debugger, Git και Profiler

nikosst — Wed, 10 Jun 2026 14:41:33 +0000

Η ανάπτυξη λογισμικού το 2026 έχει αλλάξει δραματικά. Ο σύγχρονος προγραμματιστής δεν γράφει απλώς κώδικα· συνεργάζεται καθημερινά με AI Agents, εργαλεία αυτόματης δημιουργίας κώδικα, συστήματα debugging, profiling και πλατφόρμες διαχείρισης εκδόσεων. Η πρόκληση πλέον δεν είναι μόνο να γνωρίζει κάποιος προγραμματισμό, αλλά να ξέρει ποιο εργαλείο πρέπει να χρησιμοποιήσει σε κάθε στάδιο του Software Development Lifecycle.

Ένας senior developer ή software architect οφείλει να επιλέγει το κατάλληλο εργαλείο ανάλογα με το πρόβλημα που αντιμετωπίζει. Η λανθασμένη χρήση ενός AI Agent για απλό debugging μπορεί να οδηγήσει σε χαμένο χρόνο, ενώ η χρήση ενός profiler σε πρόβλημα λογικής δεν θα προσφέρει καμία αξία. Η πραγματική παραγωγικότητα προκύπτει όταν κάθε εργαλείο χρησιμοποιείται στο σωστό σημείο της διαδικασίας ανάπτυξης.

Στο άρθρο αυτό αναλύουμε τα σημαντικότερα εργαλεία της σύγχρονης ανάπτυξης λογισμικού, τον ρόλο τους, τις βέλτιστες πρακτικές χρήσης τους και το κόστος των δημοφιλέστερων μοντέλων της αγοράς.

1. Ask Mode – Όταν χρειάζεσαι γνώση και καθοδήγηση

Το Ask Mode είναι η πιο απλή μορφή αλληλεπίδρασης με ένα AI σύστημα. Ο προγραμματιστής θέτει ερωτήσεις και λαμβάνει απαντήσεις, εξηγήσεις ή παραδείγματα.

Χρησιμοποίησέ το όταν:

Θέλεις να κατανοήσεις μια βιβλιοθήκη ή framework.
Αναζητάς βέλτιστες πρακτικές.
Θέλεις επεξήγηση ενός error message.
Χρειάζεσαι παραδείγματα κώδικα.

Μην το χρησιμοποιείς όταν:

Απαιτείται αλλαγή σε πολλά αρχεία.
Χρειάζεται ανάλυση ολόκληρου project.
Πρέπει να γίνει refactoring μεγάλης κλίμακας.

Το Ask λειτουργεί σαν ένας πολύ έμπειρος συνάδελφος που απαντά σε ερωτήσεις, αλλά δεν αναλαμβάνει εργασία.

2. Plan Mode – Πριν γράψεις γραμμή κώδικα

Το μεγαλύτερο λάθος των περισσότερων ομάδων είναι ότι ξεκινούν να υλοποιούν χωρίς σχέδιο.

Το Plan Mode δημιουργήθηκε ακριβώς για αυτόν τον λόγο.

Χρησιμοποίησέ το όταν:

Σχεδιάζεις νέο feature.
Θέλεις να σπάσεις ένα έργο σε tasks.
Κάνεις migration συστήματος.
Προετοιμάζεις αρχιτεκτονική λύση.

Παράδειγμα

Αντί να ζητήσεις:

"Γράψε authentication"

ζήτησε:

"Σχεδίασε authentication architecture για .NET microservices με JWT και refresh tokens."

Το αποτέλεσμα θα είναι σαφώς καλύτερο.

Οι senior engineers επενδύουν περισσότερο χρόνο στον σχεδιασμό παρά στην υλοποίηση.

3. Agent Mode – Ο ψηφιακός συνεργάτης

Το Agent Mode αποτελεί τη μεγαλύτερη εξέλιξη των τελευταίων ετών.

Ένας Agent δεν απαντά απλώς σε ερωτήσεις. Μπορεί να:

διαβάσει ολόκληρο repository,
αναλύσει requirements,
τροποποιήσει πολλαπλά αρχεία,
δημιουργήσει tests,
κάνει refactoring,
ανοίξει Pull Requests.

Χρησιμοποίησέ το όταν:

Υπάρχει μεγάλο codebase.
Θέλεις αυτοματοποίηση εργασιών.
Κάνεις modernization legacy εφαρμογών.
Χρειάζεσαι end-to-end υλοποίηση.

Μην το χρησιμοποιείς όταν:

Έχεις μια απλή απορία.
Χρειάζεται μόνο ένα μικρό snippet.

Ο Agent λειτουργεί περισσότερο σαν junior-to-mid developer παρά σαν chatbot.

4. GitHub Copilot – Ο καθημερινός βοηθός προγραμματισμού

Το GitHub Copilot είναι το πιο διαδεδομένο AI εργαλείο ανάπτυξης λογισμικού.

Βρίσκεται μέσα στο IDE και προσφέρει:

autocomplete,
code generation,
chat assistance,
code reviews,
agent workflows.

Χρησιμοποίησέ το όταν:

Γράφεις καθημερινό κώδικα.
Δημιουργείς APIs.
Υλοποιείς CRUD λειτουργίες.
Γράφεις unit tests.

Πλεονεκτήματα

Μικρό context switching.
Εξαιρετική ενσωμάτωση σε VS Code.
Υψηλή παραγωγικότητα.

Περιορισμοί

Δεν κατανοεί πάντα ολόκληρη την αρχιτεκτονική.
Μπορεί να παράγει λανθασμένο κώδικα.
Απαιτεί code review.

5. Debugger – Το εργαλείο που δεν αντικαθίσταται

Παρά την πρόοδο της τεχνητής νοημοσύνης, κανένα εργαλείο δεν αντικαθιστά έναν σωστά χρησιμοποιημένο debugger.

Χρησιμοποίησέ τον όταν:

Υπάρχει runtime σφάλμα.
Οι τιμές μεταβλητών είναι λανθασμένες.
Το σύστημα συμπεριφέρεται διαφορετικά από το αναμενόμενο.

Βέλτιστη πρακτική

Reproduce.
Breakpoint.
Step Through.
Root Cause Analysis.

Οι καλύτεροι developers δεν μαντεύουν. Μετρούν.

6. Git – Η ασφάλεια του project

Το Git είναι το θεμέλιο κάθε σύγχρονης ομάδας ανάπτυξης.

Χρησιμοποίησέ το για:

Version control.
Feature branching.
Pull Requests.
Code Reviews.
Rollback.

Senior πρακτικές

Feature branches.
Squash merges.
Atomic commits.
Protected main branch.

Χωρίς Git δεν υπάρχει ασφαλής ανάπτυξη λογισμικού.

7. Profiler – Όταν η εφαρμογή είναι αργή

Ένα από τα συνηθέστερα λάθη είναι η βελτιστοποίηση χωρίς μετρήσεις.

Ο profiler δείχνει:

CPU bottlenecks,
memory leaks,
database latency,
inefficient algorithms.

Χρησιμοποίησέ τον όταν:

Υπάρχουν προβλήματα απόδοσης.
Αυξάνεται η κατανάλωση μνήμης.
Υπάρχουν μεγάλοι χρόνοι απόκρισης.

Μην τον χρησιμοποιείς όταν:

Υπάρχει λογικό bug.
Το πρόβλημα είναι business logic.

8. Test Generation – Η ασπίδα της ποιότητας

Τα σύγχρονα AI εργαλεία μπορούν να δημιουργούν:

Unit Tests
Integration Tests
API Tests
Regression Tests

Χρησιμοποίησέ τα όταν:

Προσθέτεις νέα features.
Κάνεις refactoring.
Κάνεις modernization.

Ένα καλό σύστημα testing μειώνει δραματικά το τεχνικό χρέος.

Να θυμάσαι!

Ο σύγχρονος προγραμματιστής δεν ανταγωνίζεται πλέον την τεχνητή νοημοσύνη· συνεργάζεται μαζί της. Η πραγματική αξία δεν βρίσκεται στο ποιο εργαλείο είναι «καλύτερο», αλλά στο πότε χρησιμοποιείται το καθένα.

Για καθημερινό development, το GitHub Copilot παραμένει η πιο αποδοτική επιλογή. Για σύνθετες αλλαγές σε μεγάλα codebases, οι AI Agents και το Codex προσφέρουν τεράστια επιτάχυνση. Για σχεδιασμό αρχιτεκτονικής, το Plan Mode μειώνει τα λάθη πριν γραφτεί κώδικας. Για κατανόηση και εκπαίδευση, το Ask Mode είναι ιδανικό. Όταν εμφανίζονται σφάλματα, ο Debugger παραμένει αναντικατάστατος, ενώ ο Profiler είναι το μοναδικό εργαλείο που μπορεί να αποδείξει με δεδομένα πού πραγματικά χάνεται η απόδοση.

Οι κορυφαίοι software engineers του 2026 δεν είναι αυτοί που γράφουν περισσότερο κώδικα. Είναι εκείνοι που ξέρουν να συνδυάζουν σωστά ανθρώπινη εμπειρία, αρχιτεκτονική σκέψη και AI εργαλεία, δημιουργώντας λογισμικό ταχύτερα, ασφαλέστερα και με υψηλότερη ποιότητα.

nikosstit@gmail.com

Local Time, UTC, Offset και Epoch: Ο απόλυτος οδηγός για developers

nikosst — Tue, 09 Jun 2026 21:29:38 +0000

Το πρόβλημα της ώρας

Η ώρα είναι από τα πιο ύπουλα προβλήματα στην ανάπτυξη λογισμικού.

Αν ένας χρήστης στην Αθήνα δημιουργήσει μια παραγγελία στις 20:00 και ένας άλλος στη Νέα Υόρκη τη δει στις 13:00, ποια είναι η "σωστή" ώρα;

Αν μια εφαρμογή αποθηκεύσει μόνο το 20:00, χωρίς να γνωρίζει τη ζώνη ώρας, τότε η πληροφορία είναι πρακτικά άχρηστη.

Αυτός είναι ο λόγος που υπάρχουν έννοιες όπως:

Local Time
UTC
UTC Offset
Epoch / Unix Timestamp

Δεν δημιουργήθηκαν για να μας μπερδεύουν. Δημιουργήθηκαν για να λύνουν το πρόβλημα της παγκόσμιας διαχείρισης χρόνου.

Local Time

Το Local Time είναι η ώρα που βλέπει ο χρήστης στη χώρα του.

Παραδείγματα:

Αθήνα:    2026-06-09 20:00
Λονδίνο:  2026-06-09 18:00
Νέα Υόρκη:2026-06-09 13:00

Όλες οι παραπάνω ώρες μπορεί να αντιστοιχούν στην ίδια ακριβώς χρονική στιγμή. Συνέβει ένα γεγονός μία ενέργεια στον πλανίτη γη ακριβώς αυτή την στιγμή που όμως για διαφορετικές γεωγραφικές περιοχές αντιστοιχεί σε διαφορετικές ώρες.

Πότε χρησιμοποιούμε Local Time;

Μόνο για εμφάνιση στον χρήστη.

Παραδείγματα:

Ημερομηνία παραγγελίας
Ώρα δημιουργίας post
Ημερολόγιο συναντήσεων
Reports προς τον χρήστη

Πότε ΔΕΝ το αποθηκεύουμε;

Σχεδόν ποτέ ως μοναδική πηγή αλήθειας.

Αν αποθηκεύσεις:

2026-06-09 20:00

δεν γνωρίζεις:

Σε ποια χώρα δημιουργήθηκε
Σε ποια ζώνη ώρας ανήκει
Αν ίσχυε θερινή ώρα (DST)

UTC (Coordinated Universal Time)

Το UTC είναι η παγκόσμια αναφορά χρόνου.

Όλες οι ζώνες ώρας υπολογίζονται σε σχέση με αυτό.

Παράδειγμα:

UTC: 2026-06-09 17:00

Την ίδια στιγμή με βάση την UTC ώρα μπορούμε να έχουμε:

στην Αθήνα   UTC+3 -> 20:00
στο Λονδίνο UTC+1 -> 18:00
στη Νέα Υόρκη UTC-4 -> 13:00

Πότε χρησιμοποιούμε UTC;

Σχεδόν πάντα στο backend.

Αποθηκεύουμε:

2026-06-09T17:00:00Z

Το Z σημαίνει UTC.

Γιατί;

Επειδή:

Δεν αλλάζει με DST
Δεν εξαρτάται από χώρα
Είναι παγκόσμιο σημείο αναφοράς

Ένας κανόνας που ακολουθούν σχεδόν όλες οι μεγάλες εταιρείες:

Store in UTC, display in Local Time.

UTC Offset

Παραδείγματα:

UTC+3
UTC+2
UTC-5
UTC+9

Για την Αθήνα:

Χειμώνας -> UTC+2
Καλοκαίρι -> UTC+3

Χειμώνας -> UTC+2
Καλοκαίρι -> UTC+3

Παράδειγμα

2026-06-09T20:00:00+03:00

σημαίνει:

Τοπική ώρα: 20:00
Offset: +03:00
UTC: 17:00

Πότε αποθηκεύουμε Offset;

Όταν θέλουμε να γνωρίζουμε ακριβώς τι έβλεπε ο χρήστης τη στιγμή της καταχώρησης.

Παραδείγματα:

Αεροπορικά εισιτήρια
Νομικά έγγραφα
Ιατρικά συστήματα
Financial systems

Epoch / Unix Timestamp

Το Epoch είναι η πιο "καθαρή" αναπαράσταση χρόνου.

Μετράει πόσα δευτερόλεπτα έχουν περάσει από:

1970-01-01 00:00:00 UTC

Αυτό ονομάζεται Unix Epoch. epochconverter

Παράδειγμα:

1780968655

Αυτός είναι απλά ένας αριθμός.

Δεν περιέχει:

Timezone
Offset
DST

Μόνο μια απόλυτη χρονική στιγμή.

Γιατί οι developers αγαπούν τα Epochs;

Επειδή οι συγκρίσεις είναι πανεύκολες.

Αν έχεις:

1780968655
1780968755

ξέρεις αμέσως ότι το δεύτερο συνέβη αργότερα.

Δεν χρειάζεται:

μετατροπή timezone
parsing
date calculations

Timestamp ως Long

Στη .NET και στις περισσότερες γλώσσες το Epoch αποθηκεύεται ως:

long timestamp

Παράδειγμα:

1780968655

1780968655000

(σε milliseconds)

Πότε χρησιμοποιείται;

Databases
APIs
Event streams
Kafka
Message queues
Logging systems

Timestamp ως String

Παράδειγμα:

2026-06-09T17:00:00Z

2026-06-09T20:00:00+03:00

Αυτό είναι συνήθως ISO 8601 format.

Πλεονεκτήματα

Αναγνώσιμο από άνθρωπο
Περιέχει timezone πληροφορία
Ιδανικό για APIs

Μειονεκτήματα

Μεγαλύτερο μέγεθος
Πιο αργό parsing

Timestamp ως DateTime

Στη .NET:

DateTime DateTimeOffset

Σήμερα οι περισσότεροι senior developers προτιμούν:

DateTimeOffset

γιατί περιέχει και το offset.

Παράδειγμα:

2026-06-09 20:00 +03:00

Τι να χρησιμοποιήσω τελικά;

Για αποθήκευση στη βάση

Προτίμησε:

UTC ή DateTimeOffset

Για APIs

Προτίμησε:

ISO 8601

Παράδειγμα:

{
  "createdAt": "2026-06-09T17:00:00Z"
}

Για logs

Προτίμησε:

UTC

ή Epoch.

Για sorting και performance

Προτίμησε:

Epoch Timestamp

Για εμφάνιση στον χρήστη

Προτίμησε:

Local Time

με βάση τη ζώνη ώρας του χρήστη.

Τι είναι το Epoch Converter;

Το Epoch Converter είναι ένα πολύ γνωστό εργαλείο για developers που μετατρέπει:

Epoch → Human Readable Date
Date → Epoch
UTC ↔ Local Time
Seconds ↔ Milliseconds ↔ Microseconds

και υποστηρίζει διάφορες μορφές timestamps.

Είναι εξαιρετικά χρήσιμο όταν κάνεις debugging logs, APIs ή βάσεις δεδομένων.

Συμπέρασμα

Το μεγαλύτερο λάθος που κάνουν οι developers είναι να θεωρούν ότι η ημερομηνία είναι απλώς ένα πεδίο στη βάση.

Στην πραγματικότητα, ο χρόνος είναι ένα παγκόσμιο πρόβλημα συγχρονισμού. Το Local Time εξυπηρετεί τον χρήστη, το UTC εξυπηρετεί το σύστημα, το Offset διατηρεί το πραγματικό τοπικό πλαίσιο μιας στιγμής και το Epoch παρέχει την πιο απλή και απόλυτη αναπαράσταση του χρόνου.

Όταν σχεδιάζεις ένα σύστημα, η σωστή ερώτηση δεν είναι «ποιο type να χρησιμοποιήσω;». Η σωστή ερώτηση είναι:

Θέλω να αποθηκεύσω πώς είδε ο χρήστης την ώρα ή ποια ακριβώς στιγμή συνέβη το γεγονός;

Αν απαντήσεις σωστά σε αυτή την ερώτηση, τότε η επιλογή μεταξύ Local Time, UTC, Offset και Epoch γίνεται σχεδόν αυτονόητη. Οι καλύτερες εφαρμογές δεν είναι αυτές που χειρίζονται σωστά τις ημερομηνίες στις εύκολες περιπτώσεις· είναι αυτές που συνεχίζουν να λειτουργούν σωστά όταν οι χρήστες βρίσκονται σε διαφορετικές ηπείρους, αλλάζουν ζώνες ώρας ή όταν η θερινή ώρα αποφασίζει να σου χαλάσει το βράδυ παραγωγής.

Το πιο γνωστό και ευρέως χρησιμοποιούμενο εργαλείο μετατροπής Unix timestamps για developers.

Online εργαλείο μετατροπής Unix Epoch timestamps σε αναγνώσιμες ημερομηνίες και αντίστροφα.

Developer-focused εργαλείο για μετατροπές Epoch, UTC και ISO 8601 timestamps.

Web εφαρμογή για μετατροπές Unix time, debugging και date calculations.

Minimalistic converter για γρήγορη μετατροπή Epoch timestamps και ημερομηνιών.

Online converter με υποστήριξη Epoch, UTC, timezone conversions και date utilities.

Εργαλείο μετατροπής Unix timestamps με έμφαση σε προγραμματιστικές χρήσεις και APIs.

Πληροφοριακό site για Unix Time με converter και επεξήγηση του Epoch format.

Unix timestamp calculator με δυνατότητες date arithmetic και μετατροπών χρόνου.

nikosstit@gmail.com

DEV Community: nikosst

Fake και Mock στα Unit Tests με παραδείγματα και Clean Architecture

Τι ελέγχει ένα unit test

Η οικογένεια των test doubles

Η βασική διαφορά Fake και Mock

Το παράδειγμα που θα χρησιμοποιήσουμε

Ο κώδικας της εφαρμογής

Πρώτα δοκιμάζουμε τον απλό κώδικα χωρίς doubles

Ο ίδιος έλεγχος με Fake

Μια σημαντική παγίδα με mutable αντικείμενα

Ο ίδιος έλεγχος με Mock

Γιατί χρησιμοποιούμε autospec και spec_set

Πότε το mock είναι ιδιαίτερα βολικό

Fake και Mock στο ίδιο test

Τα Fakes χρειάζονται δικά τους tests

Εκτέλεση των παραδειγμάτων

Πότε προτιμάμε κάθε προσέγγιση

Πώς συνδέεται αυτό με την Clean Architecture

Η σχέση με το SOLID

Single Responsibility Principle

Open Closed Principle

Liskov Substitution Principle

Interface Segregation Principle

Dependency Inversion Principle

Best practices για καθαρά και χρήσιμα tests

Γράφουμε ένα test για μια συγκεκριμένη συμπεριφορά

Κρατάμε καθαρά τα Arrange Act Assert

Επαληθεύουμε μόνο τις αλληλεπιδράσεις που έχουν σημασία

Δεν αντικαθιστούμε με mock τη συμπεριφορά που εξετάζουμε

Κάθε test ξεκινά με δική του κατάσταση

Τα tests παραμένουν απλά

Δεν αφήνουμε το fake να γίνει δεύτερη βάση δεδομένων

Κρατάμε τα εξωτερικά SDKs πίσω από χρήσιμα όρια

Ελέγχουμε τις αποτυχίες και τα όρια

Χρησιμοποιούμε το coverage ως ένδειξη

Τι δεν αποδεικνύουν τα unit tests του παραδείγματος

Πώς αποφασίζουμε στην πράξη

Expression Mapping, Projection και Specification με ένα απλό παράδειγμα

Aggregates στο Domain-Driven Design: Πώς και γιατί τα χρησιμοποιούμε σε C# και .NET

1. Τι είναι ένα Aggregate;

Παράδειγμα

2. Γιατί χρειαζόμαστε Aggregates;

3. Aggregate Root vs Entity vs Value Object

Entity

Value Object

Aggregate Root

4. Υλοποιώντας το OrderItem Entity

5. Υλοποιώντας το Order Aggregate Root

Τι κερδίσαμε;

6. Aggregates και Entity Framework Core

7. Repository Pattern και Aggregates

Χρειαζόμαστε πάντα Repository Pattern;

8. Aggregates μέσα στην Clean Architecture

Application Handler

9. Aggregate = Consistency Boundary

Πώς επικοινωνούν διαφορετικά Aggregates;

10. Πώς αποφασίζουμε τα Aggregate Boundaries;

Ερωτήσεις που πρέπει να κάνουμε

Ένας πρακτικός κανόνας

11. Aggregates και Concurrency

Optimistic Concurrency με EF Core

12. Unit Testing των Aggregates

13. Συνηθισμένα λάθη στην εφαρμογή Aggregates

Λάθος 1: Public Setters παντού

Λάθος 2: Ένα Aggregate για ολόκληρο το Domain

Λάθος 3: Business Logic στα Application Services

Λάθος 4: Repository για κάθε Entity

Λάθος 5: Σύγχυση Aggregate και Database Transaction

Λάθος 6: Χρήση Aggregates χωρίς πραγματικούς κανόνες

14. Πότε πρέπει να χρησιμοποιούμε Aggregates;

15. Τελικές σκέψεις

Further Reading

dotnet #csharp #architecture #ddd

CQRS χωρίς MediatR στο .NET: Custom Implementation, Clean Architecture και Dependency Inversion

Εισαγωγή

1. Τι ακριβώς προσφέρει το CQRS;

2. CQRS και Mediator: δύο διαφορετικές έννοιες

3. Η αρχιτεκτονική δομή της υλοποίησης

4. Πρώτο βήμα: Ορίζουμε τα contracts του CQRS

4.1 Command contracts

Και τι κάνει το `[Authorize]`;