CODEWITHSUNDEEP
c#design-patternsarchitecturedomain-driven-designonion-architecture
Rénald
Rénald

Reputation: 1430

Onion Architectures, persistence and notifications

I am studying Onion Architectures and I have a point.

Onion Architectures aim at isolating the Domain from technological artifacts. Therefore, the guideline is to let the Data Access Layer (DAL) reference the Domain Layer (BL). This way, I should be able to transform entities into storage artifacts. Referencing the BL should probably give me a "snapshot" of my Domain, but without a change-tracking system I will loose all chronological events to know whether inserting, updating, or deleting items in the data-store, to be able to correctly rehydrate the model afterwards.

Do Onion Architectures always need some change-tracking systems, or even something like an event-store ? Am I missing any other pattern ?

Upvotes: 3

Views: 739

Answers (2)

Batavia
Batavia

Reputation: 2497

Does the domain layer know when it needs persisting?

For example i might have a new/update customer screen that saves a new customer when i press finish. At that point i don't care about change tracking, i want to just store everything that i have. and my DAL can figure out if i already have a customer with the same name in the database or not (if it should emit insert or update queries).

Same thing applies to to an event store. And event store if an technical implementation if your domain cares about events, being able to undo event, etc etc,

What might happen is that your Domain Layer always consist of a complete in memory up live mutating system. In that case there isn't even a snapshot.

The onion architecture just describes to separation of artifacts. Which artifacts they are will really depend on particular requirements.

Upvotes: 3

guillaume31
guillaume31

Reputation: 14064

The Application layer is supposed be in charge of that. An Application Service implements a use case by orchestrating calls to the domain. Domain entities created or modified as part of the use case must be held in memory in one form or another for later persistence.

The typical way to do it is to place them into a Unit of Work (whose implementation resides in the Infrastructure Layer). It tracks the modifications made to domain entities. When the Application Service ends the business transaction, the Unit of Work will translate the entities state into something flushable to a persistent store.

Upvotes: 2

Related Questions