How does this kind of application and DDD relate?

Question

In Domain-Driven Design the application is divided, as I understand, into four layers:

• Presentation Layer
• Application Layer
• Domain Layer
• Infrastructure Layer

I understand this well, for instance, when developing desktop applications with, for instance, WPF on Windows.

Now, there's another kind of application that personally I find very important today. I don't know if there's one technical term yet for this kind of application (probably there is but I didn't find it yet), but I'll describe it.

We have one server hosting one N-tier application that has one RESTful Web API where clients can make requests. The other tiers are for background processing and communicating with devices, sending notifications and so on. This kind of architecture is seem on Microsoft Azure Cloud Services, for instance, where we can host multiple web roles (the Web API, for instance) and multiple worker roles (which do background processing).

Now I fail to see how can I relate this to the kind of division DDD does of an application.

The domain layer is of course on the server and the requests to the API as well as the background processing have side effects on the domain model. The infrastructure layer is also on the server.

On my understanding, the application layer is this whole N-tier application (in Azure case, composed of all web and worker roles).

But finally, there's no presentation. This thing is an API, it is built to deal with tons of devices. Web browsers, smartphones, tablets and so on.

I'm trying to benefit from DDD on this kind of application, but I'm failing to see how both relate. How does this kind of application and DDD relate and how can one benefit from DDD on those scenarios?

Answer 1

I don't think they necessarily relate at all. DDD is about designing software from a business domain perspective, utilizing an ubiquitous language that you and your customer both understand. Many software developers mistake it for a programming technique, but it's more of a way to organize potential software structures (i.e. classes) around business domain concepts. Software layers don't really have much to do with that, inasmuch as they're merely a different (but sometimes complementary) abstraction.