DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Responsibilities of the Application Layer in Domain-Driven Applications

Dan Haywood user avatar by
Dan Haywood
·
Sep. 26, 12 · Interview
Like (0)
Save
Tweet
Share
15.52K Views

Join the DZone community and get the full member experience.

Join For Free

It’s standard practice to build enterprise apps in layers: each layer has its own set of responsibilities, providing a separation of concerns.  In Evans’ DDD book, layered architecture is one of his named patterns, its intent being to isolate the domain layer from the adjacent layers of application and infrastructure.  The presentation layer is, of course, the other standard layer, sitting on top of the application layer:

  • presentation layer
  • application layer
  • domain layer
  • infrastructure layer

Of these layers, though, it’s the application layer that seems to cause the most difficulty, and is a regular topic of conversation on the yahoo DDD forum. My contention is that most people put too much responsibility into this layer, writing reams of boilerplate code. Maintaining all this code impairs the development of the larger goal, the ubiquitous language. (Of course, maintaining reams of code in the presentation layer exacerbates this even further; I’ll come back to this in a minute).

In a recent thread on the DDD group, I tried to elicit a list of the responsibilities of this application layer. The list of responsibilities for the application layer that were eventually identified in that thread ended up as:

  1. to allow presentation layer vs domain layer to run in different processes/machines
  2. to implement cross-cutting concerns such as security and transaction management.
  3. to map identities and DTOs into domain objects that can be delegated to (hexagonal ports and adapters pattern)
  4. (if you don’t own the client, or if the client isn’t generic), to provide a stable API that allows domain entities to be refactored without changing the client
  5. (if required) to provide an ability to support different client versions concurrently
  6. (if dependency injection into entities is not used) to pass domain services into entities
  7. (if a domain module representing users/user identity does not exist), to map system level user identity into a representation that can be passed into entity method calls
  8. to assemble domain entities with respect to specific use cases (view models)

My contention in that thread is that most, and many times all, of these responsibilities can be implemented generically within framework code. In other words there is no need to maintain custom-written code in the application layer. Doing this does require making some explicit design choices, most notably:

  • dependency injection into entities, to obviate the need to pass domain services into entities, and
  • a domain module representing users, to obviate the need for the application layer to map user Ids

Of course, the naked objects frameworks (Apache Isis, NO MVC) do this for you. Moreover, they also produce a generic (though customizable) presentation layer. The benefit of this is that you can focus just on the domain model, ie building your ubiquitous language.

It’s a shame that most people who encounter naked objects don’t get this, and would rather spend their days labouring away maintaining those other layers. That said, I have a sneaking suspicion that lots of developers like doing this: writing lots and lots of boilerplate code. Well, I guess it’s easier than trying to think deeply about your domain model! But I don’t think that’s what Evans had in mind when he included the layered architecture pattern in his book.

application

Published at DZone with permission of Dan Haywood, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Explainer: Building High Performing Data Product Platform
  • Playwright vs. Cypress: The King Is Dead, Long Live the King?
  • How to Secure Your CI/CD Pipeline
  • Web Application Architecture: The Latest Guide

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: