This is my understanding of the Application Layer:
• It implements Application logic
• this layer contains Application Services, which are used by external consumers to talk to your application
• Application Services are coarse-grained and orchestrate operations which map directly to use cases ( hence also the term Workflow Services )
1)
From:
Application Logic is mostly workflow logic. It is the application
specific coordination of domain and infrastructure components
according to the requirements of that particular application.
Let's start a company, shall we? Sapient Grey will be primarily a
think tank, but with an in-house development group with the
capabilities to make the visions of the core committee a reality. Our
corporate motto, "Sapient Grey is People…" will be burnished in
giant brazen letters alongside a customized version of Rodin's famous
sculpture "The Thinker", all of which will adorn the east-facing side
of our brand new ten story red granite office building…. Oh, wait.
We don't have an office building yet. Okay then, so we'll hire an
architect to design our office building, being sure to include a
private elevator and an elaborate zen-style atrium or courtyard in the
center. In the meantime, while the building is being designed and
constructed, you and I and our other elite colleagues will fly
ourselves to Tahiti to brainstorm Sapient Grey's visions, goals,
agenda, and lay out a detailed business plan.Our architect is creating detailed blueprints for the office building, figuring out how
the plumbing will need to be laid out, how the electrical systems will
be segregated and tied together, how the interoffice communication
system will be organized, and how we will implement security at all
levels. The systems and designs that our building architect is
handling is a precise analogy to what "Application Logic" is within a
web application. How security is implemented, how we will manage and
access state and persistence, how we will handle storage and retrieval
of data….this is application logic. Like our office building, which
when complete could house and accommodate anything from an elite night
club to an investment firm, the application logic is independent of
the actual business logic that executes within it.
a) The above quotes are two different definitions of the term Application Logic and as such it appears they just happen to use the same term (ie Application logic) to describe two different concepts. Thus, does only the the first definition describe the logic contained in Application layer, while the latter definition is describing a different kind of logic?
b) If indeed both definitions describe the logic in Application layer, then wouldn't this mean that Application layer performs two tasks: orchestrating operations that map directly to use cases and executing non-business related logic (such as security, caching etc)?
Best Answer
I am the one that posted the article in the first quote and I must admit I wasn't quite clear in that "definition" of application logic. When I said "mostly" I should definitely have said "sometimes".
Application Logic (hopefully concentrated in an application layer and not scattered across the BBOM) is any logic that is specific to some application. It is fundamentally different from Domain Logic and Infrastructure Logic in terms of target and re-usability: Domain Logic is the logic solving problems in the domain of interest and it should be totally reusable in applications addressing the same domain context but exposing different features. Infrastructure Logic is about generic technical capabilities that should be reusable in any application from any domain.
Having said that, your application logic can be entirely concentrated in some services exposing a feature-oriented coarse-grained interface, in a procedural fashion if the logic is fairly simple (similar to Fowler's Transaction Script pattern, although the target of this pattern is Domain Logic organization – it can be extended to application logic as well).
On the other hand, if your application logic has a fair degree of complexity (such as complicated dynamic wizard-style flows or the need to restrict user access to certain subsets of domain logic and data function of complicated combinations of permissions assigned to various user roles) it's worth building an object model of the application specific concepts. This object model can sit behind a feature-oriented coarse-grained facade (logical service) but the application logic is not anymore just the orchestration provided by the feature-oriented service but the behavior in the object model behind it as well.