5

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.

enter image description here

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)?

Improve this question
5
  • 1
    It would be more accurately called the Business Logic Layer. Your domain is whatever your software is about, eg: online shop has a domain covering carts, bills, customers, products, etc...
    – Kain0_0
    Jan 15 '20 at 6:33
  • 1
    the entities belong to the domain layer (domain services + domain entities) - dto to the data access.
    – Christophe
    Jan 15 '20 at 9:56
  • @Kain0_0 depends on architectural framework. Onion architecture and Martin Fowler call this domain. Others call this the business layer or the use case layer. So I’d stay flexible on the naming ;-)
    – Christophe
    Jan 15 '20 at 10:00
  • Love the diagram - really helps us to understand what you're asking
    – JBRWilkinson
    Jan 15 '20 at 14:05
  • 1
    @Christophe +1 to your answer below.
    – Kain0_0
    Jan 15 '20 at 22:51
6

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:

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.

Improve this answer
1
  • 1
    Thanks. The Clean Architecture is actually the closest to what we are doing. The DTOs are in that 'middle layer' as they are simply anemic vessels which carry data up to the Presentation layer. None of my entities will rise above the business layer, as they are not View-centric in nature. But I can see the wisdom in separating them from the data access code. For an app this size, it would be a 'logical separation', as having them in a whole new physical layer would be overkill. Again, thanks a lot for your feedback.
    – onefootswill
    Jan 15 '20 at 21:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.