I think of the application layer ( = service layer ) as a high level
simple (facade) API, oriented around steps in use case scenarions and
reusable from different GUI:s (i.e. I think service/application layer
is the same thing as Larman describes as GRASP Controller, being the
first object beyond the GUI layer that delegates to the domain layer,
and should be reusable from different GUI:s)

I think such a (GRASP) Controller in the application layer could have
one method like this:
sessionId = ShoppingController.addItem(sessionId, itemId);
which is invoked everytime a user clicks a button. The first time, the
sessionId parameter will be null, and then the server will return a id
that the web layer needs to keep for the subsequent invocations, and
provide as parameter when adding additional items.
The items might be stored as a "Database Session State"
(http://martinfowler.com/eaaCatalog/databaseSessionState.html)

When the user have added all items, he will maybe go to a web form
with name and address and so on.
When such a form page is submitted, a method like this might become
invoked:
ShoppingController.placeOrder(sessionId, name, adress, ...)

This kind of GRASP Controller / Service Layer / Application Layer can
be reused from other GUI:s also, though in the email example mentioned
by Rickard, there needs to be some kind of "email/POP3 layer"
(="integration gateway layer" maybe?) and some data extracion from the
email content. For example, if the protocol of the email order is that
the first X rows of the email are supposed to contain address
information and then the rest of the rows have an itemId per row, then
all itemId's from the email can be iterated and then invoke the
"addItem" method as many times as there are rows with items, and then
the "placeOrder" might finally be invoked.
The sessionId created by the method "addItem" can thus be a database
generated Id, and need not be a web session id.

On the other hand, another possible design of the high-level
Application/Service/GraspController layer is to only provide one
method with all the data, including an array with item Id's, such as:
ShoppingController.placeOrder(itemIds[], name, adress, ...)

Then the web client needs to maintain all itemId's that are clicked,
so you put some extra stuff into the web layer with this kind of API.
However, when you want to parse an email, this kind of API will feel
more natural, without doing a bit awkward roundabout by multiple
invocations of an "addItem" method.

To reiterate, I think of the service/application layer (GRASP
controller) in terms of steps in a use case scenario, e.g. when a
button is clicked in a web application or a swing application, I try
to think of which kind of data values will be sent as parameters, e.g.
will be coming from textfields, and radiobuttons and so on. And
regarding the returned data from the app layer, I think of what kind
of data will need to be returned from a method, to become displayed in
the GUI, or needs to be returned for other reasons, such as a need for
saving a sessionId.

I think the application interface should be defined as a facade with
very simple API methods for the input parameters, to make it easy to
reuse from other clients, and to avoid duplication. In Larman's book I
think he has too much duplication in the GRASP controller example
(page 309-311) where he has a "Register" controller that he invokes
with "register.enterItem(id, qty)". The duplication is that both
Struts code and the Swing code are using the same kind of code that
transforms a String (from either a Swing textfield, or from the Struts
form property) to either an item itemId or an int.
(e.g. these to rows are duplicated:
ItemID id = Transformer.toItemID(txtId);
int qty = Transformer.toInt(txtQty);
) and I think that code should be reused instead, i.e. handled from
within the GRASP Controller (application/service layer).

Above I mentioned that I think in terms of button clicks in web apps
or window/swing apps, but of course one could also choose to think of
a incoming SOAP request or an incoming email as the triggering event,
instead of button clicks. Anyway, I think of the input data and the
output data, from a high level point of view, when I design my
application/service layers with GRASP controllers.
(and the input values might be coming from Swing textfields, or from
SOAP content in a web service invocation, and so on...)

Finally, I just want to explain why I think in terms of:
"Service layer" = "Application layer" = "GRASP Controller layer"

The first two are easy to explain, i.e. Service (Evans) layer is the
same as Application (Fowler) layer because Fowler himself says so, in
his "bliki" about the "Anemic Domain Model":
http://martinfowler.com/bliki/AnemicDomainModel.html
Quote:
"Application Layer [his name for Service Layer]: Defines the jobs the
software is supposed to do and directs the expressive domain objects
to work out problems. The tasks this layer is responsible for are
meaningful to the business or necessary for interaction with the
application layers of other systems. This layer is kept thin. It does
not contain business rules or knowledge, but only coordinates tasks
and delegates work to collaborations of domain objects in the next
layer down. It does not have state reflecting the business situation,
but it can have state that reflects the progress of a task for the
user or the program."

Now consider the above description (and also see fowler's PEAA book,
regarding identifying service layer methods from the use cases) and
also consider the picture in Fowler's description of Service layer
that illustrates the Service Layer being the first layer after the
"user interface" (or an "integration gateway", which I guess the email
example discussed above can be considered as being a part of) at this URL:
http://martinfowler.com/eaaCatalog/serviceLayer.html

Now compare the above mentioned Service/Application layer description
with some of Larman's words about the GRASP Controller (in the 3rd
edition of his best-selling OOAD book "Aplying UML and patterns", age
302-306) :
"...first object beyond the UI layer that receives and coordinates
("controls") a system operation..."
"...represents a use case scenario within which the system event
occurs..."
"... Normally, a controller should delegate to other objects the work
that needs to be done; it coordinates or controls the activity. It
does not do much work itself...."

I think that Larman's GRASP Controller layer is the same as
Evans/Fowler's Application/Service layer. Do other people disagree ?
Then please explain the significant differences between these concepts.

/ Tom




--- In domaindrivendesign@yahoogroups.com, Rickard Öberg
<rickardoberg@...> wrote:
>
> elbandit33 wrote:
> > Hopefully this question is not too stupid.. :0(
> >
> > Is the application layer like a Business Facade? Or can it have some
> > logic within it or should this logic be contianed only in the Domain
> > Service?
>
> I think that with many of these kinds of questions ("Where should I put
> X?") it is useful to do some hypothetical scenario, and consider what
> the role is of everything. In your case, you have a webshop
application,
> with a shopping basket, which eventually leads to order placement.
Let's
> imagine that you add another application interface, whereby it is
> possible to email orders to your application, instead of doing them
> through the web.
>
> In this case everything that has to do with placing an order and
> handling payment should be shared between the two applications. No
> matter how many ways there are to place orders, the basic business
logic
> should be the same. Therefore, put that in the domain layer. The
> shopping basket, however, is something that is specific for the web
> frontend, and is not useful with the email version, and probably not
> either if you have a rich client frontend, or similar. So put that in
> the application layer.
>
> I think by sometimes doing these kinds of mental exercises makes it
> easier to see where to put what, because it helps provide examples of
> what role each part is supposed to play. We don't just call it
> application layer because it's fun, but because it means something, and
> examples are a good way to make it more understandable.
>
> HTH,
> Rickard
>