Responsibilities of the Application Layer in Domain-Driven Applications

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.

About these ads

Posted on September 17, 2012, in Uncategorized and tagged , , . Bookmark the permalink. 8 Comments.

  1. While it’s true that some developers tend to write lots of boilerplate code, the reason need not be lack of programming finesse. The threshold for using DDD isn’t always obvious when starting out, and in cases where access to domain experts is limited (or worse, becomes restricted down the line), either the holes in the model must be patched by the developer at their own discretion (antithetical to DDD), or the developer must resort to somehow weaving the *available* concepts into a working unit outside the model (like say, the application layer). Otherwise, the product simply won’t ship. See how that works?

    • Thanks for the comment, but I must be misreading your intent. How it reads to me is that one motivation for having an explicitly coded application layer is to allow the developers to bodge the application while preserving the illusion that the domain model is “correct”. But I can’t imagine that’s what you intended to say?

      Your comment does remind me though of an observation I used to make more broadly about the naked objects pattern, in that, because you don’t (can’t) write any presentation logic, then it forces you to uncover deeper domain concepts. An example is a simple “group” widget, eg here, used to surround “related” fields such as the first name, last name, middle initial of a Customer. The concept that’s being hidden here is Name. If you don’t have the “luxury” of coding up a groupbox, then this constraint of the framework is actually beneficial: you end up digging deeper until you discover that missing concept.

  2. It sounds as if you are frustrated with the success of the Naked Object approach in general. But what is the reason for it being not successful? Is it ignorance as you suspect?
    Having made a project in a NO style, I am deeply convinced about its advantages. But, even though you are doing quite an effort to advocate the approach, it doesn’t really seem to kick off.

    • Yes, I am frustrated that NO isn’t more widely adopted than it is, but after being stagnant for a long time, things are improving. After all, Apache Isis has now graduated from the Apache incubator, and that only happens once ASF is convinced that the community is viable and self-sustaining. And the sister NO MVC project continues to attract followers too.

      As for my efforts to promote the concept, I’m not a marketeer and don’t have the inclination to become one… I’m content enough doing the type of publicity I do. That said, if anyone in the community (you?) wants to try a different approach to effectively explain and market the NO idea, I’m always willing to support them where I can.

  3. When I discovered NO, it was hard to believe there could be something so powerful, developer-friendly and brilliantly engineered in the Java community. At the same time, I didn’t understand how it could be so hidden. Having witnessed its evolution through some months (perhaps years), I sometimes think the problem may lay in the product’s lack of focus. NO tries to integrate with so many different technologies that it always seems somewhat unfinished, because it’s difficult to keep these parallel efforts stable and up-to-date as technology advances. I think that making a polished product, usable in the real world by an average programmer, would be the best marketing effort — even if at the beginning it lacked support for the most trendy technologies.

    • I think that’s a fair comment. Of course, with open source the product evolves according to the interests of the community, and with us now being an Apache top level project that will only continue.

      I do expect that we will make the product’s focus sharper over the next year, though. As a community we have already got rid of the client/server remoting support, which means in turn that the original DnD viewer is now positioned as a development tool only. For myself, I’d like to see it trimmed back further to just a few viewers: Wicket, Scimpi, and RestfulObjects (perhaps with the DnD viewer for nostalgic reasons). For the persistence layer, I’d like us to support JDO/DataNucleus, and the native NoSQL object store. But I think we could jettison the in-memory object store, the XML object store and, quite possibly, the SQL Object Store.

      Even though I’m chair of the PMC committee for Apache Isis, it’s not for me to dictate this though… the community decides. So, please get involved and help decide on the future of the product.

  4. Webapi (query and write services for clients) are part of application layer? Viewmodels, mappings, event projections for read models application layer responsibilities?

    • Yes, webapi (assuming you men the .NET library) can be used as a technology for the application layer. It’s primarily a library for writng RESTful APIs, so it supports (1), (3), (4), (5) and (8) from my list of application-layer responsibilities. Indeed, NO for .NET (with its Restful Objects support) is written on top of webapi.

      But my main point is that the code that makes the webapi calls can be in a framework, rather than written by hand.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Get every new post delivered to your Inbox.

Join 292 other followers