Is My Data Access Layer Really My Domain?

Question

I'm not an architect, but am trying to put together a diagram which represents the architecture of the application which I am maintaining.

I have one question (but welcome any comments about the diagram itself, as I have not training in this discipline).

I've essentially called the layer, where all my Application Services live and DTOs originate, the Domain.

I've called the layer which actually interacts with the database the Data Access Layer. That layer also contains the entities which get transformed into DTOs on their way through the application services.

Have I misnamed the Data Access Layer?
Would it be more accurate to call that the Domain?
Would it be more accurate to call the currently labelled Domain, the Application Layer, Business Layer or Services Layer (or something else)?

Answer 1

Usually the naming of the layers depend on the architectural approach:

• The traditional layering is presentation / business logic / data access layer.
• Another popular variant is Fowler’s presentation / domain logic / data source layer.
• More recent architectures were inspired by the (data neutral) hexagonal architecture and use a more concentric idioms, where at the inner core you have entities and domain logic and UI and database adapters are relegated to the outer circles:
  • Onion architecture
  • Clean architecture

Regardless of the naming you chose for your data access layer, the entities belong in principle to the domain. After all, they are defined as domain objects. They should therefore be independent of the underlying database.

If you follow this principle, the DAL or data source layer would contain only the glue that connects the entities with the database. This is the approach promoted by the more modern architectural models.

Nevertheless, architecture is not black or white and ultimately it’s up to you to decide based on your needs. For example, some frameworks and some architectural patterns (e.g. active record) work with entity object in the data access layers. This is frequent in contexts where domain logic is not too complex and applications that are mostly focused on data content.