Loading ...
Sorry, an error occurred while loading the content.

Service layer = Application layer = GRASP Controller layer

Expand Messages
  • dddbloke
    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
    Message 1 of 4 , Jun 10, 2008
    View Source
    • 0 Attachment
      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
      >
    • Alberto Brandolini
      Hi Tom, to me looks like just a naming issue: Larman s GRASP controller has an unfortunate naming choice, due to overlapping with the MVC Controller. If I do
      Message 2 of 4 , Jun 13, 2008
      View Source
      • 0 Attachment
        Hi Tom,

        to me looks like just a naming issue: Larman's GRASP controller has an
        unfortunate naming choice, due to overlapping with the MVC Controller.
        If I do remember correctly he plainly states that the two Cs are not
        the same, but it's sort of awkward to describe an architecture in
        terms of MVC-Controller and GRASP-Controller. A good point about this
        naming is that it emphasizes an active coordination role of the component.

        The "Service" alternative has advantages and drawbacks too: it's
        probably more widespread than the previous one. It is also a little
        more generic, cause a service can also be a "passive" component of the
        system, that can be called (only?) from other services, thus blurring
        the "coordination" connotation of the Controller name.

        I have to admit that I am not completely consistent myself, adapting
        my terminology with the one currently in use in the development
        environment (unless is totally non-sense), thus preferring ease of use
        to orthodoxy.


        Best regards

        Alberto


        --- In domaindrivendesign@yahoogroups.com, "dddbloke"
        <tomjbr.52671484@...> wrote:
        >
        > 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
        > >
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.