~ Walt
Davis (Software Architect) ~
|
Application Design Reference
Architecture |
|
Reference
architecture for creating enterprise applications – layered, responsibility
driven design, and service oriented architecture that is domain model driven;
model being a technology neutral object model of the business architecture. This
document captures the authors work in building distributed, web enabled,
object oriented applications and how to organize these applications into
systems that form the backbone of an automated and modernized line of
business. As
technology and business logic change at different rates special engineering
techniques are used to create agile solutions in which the business logic is
decoupled from the technologies through which the domain model is deployed. This drastically
reduces initial project costs and ongoing maintenance.
Domain
centric means to derive all design from a business architecture perspective.
The goal is to construct a technology independent application that retains
business objects in original form. To do
this an application’s architecture is decomposed into four types of building
blocks: service objects, presentation objects, domain objects, and data
storage objects. This
approach while simple supports long term growth using highly cohesive and
loosely coupled software layers that allow change in technology and business
processes that would otherwise cause failure in most software structures. The
concept of encapsulation is extended beyond the object point of view and is
applied to multiple layers, i.e., each layer also has a public and private
part. Services While
presentation objects, domain objects, and persistence objects form horizontal
layers that are hierarchical, service objects form a single vertical layer
with no hierarchical ordering. Horizontal
layers are therefore free to use any set of services necessary in fulfilling
its intended responsibilities. Services
can be decomposed into remote or local types but this should be transparent. Example
services might be email gateway, logging, authentication, report generation,
etc. From
an enterprise perspective you should expect to see functional services that
map directly to an organizations business processes; payments, bill process,
patient intake … thus further reinforcing a domain centric approach to
software design. Presentation
Layer This
is where you find the user interface logic. This logic captures how a user
(or other actor) interacts with the application. This interaction includes a
common look & feel, and work flow specific to each actor. At a
design level this layer is typically constructed using a MVC (Model View
Controller) architecture. It is
important to understand that the model in MVC is not a business object but is
intended to be a model of a widget such as a tree, tab, button …
inexperienced developers often mistake this model for a business object.
Implemented correctly the business object should be mapped to a widget’s
model via a controller and events. Multiple
views based on user role are possible. Although the presentation logic of
each role is decoupled from one another, they share common underlying
building blocks. In
addition to each view there may be more than one type of presentation, i.e.,
(Web, Thick Client, Wireless Application Protocol, etc). The
presentation could even be a remote API in enterprise architecture that that
represents a service to other applications/systems. All
presentations and views are built on top of the same domain model. Domain
Model Layer The
domain layer represents the business architecture by modeling the business
concepts and their relationship to one another, i.e., business logic, using
RDD (Responsibility Driven Design). RDD is
a very specific type of object oriented design. Understand that through this process
the model produced will start out as an analysis model, transform into a
design model, and finally become an implementation model. Using
native programming language constructs decoupled from persistence, UI, or
other technologies; this is where the business logic is contained. Done
correctly the implemented model should directly reflect the original business
architecture. A
couple of key design goals are: 1. Capture and retaining the business architecture in
its purest form. 2. Support for multiple presentations and views
without need for specific customization of the domain layer to the needs of
any one specific point of view. When
driving software construction from the domain layer the concepts within this
layer are reflected outward throughout the other layers in a vertical
fashion. Once again reinforcing the idea of driving design from the business
architecture. This
effect is often termed “Domain Centric” and greatly simplifies the software
construction process. It drastically reduces the gap between business and
technical architecture. To
navigate the software structure one must understand the business architecture
and navigate its concepts across the technology layers that wrap the domain
model. The
domain model is often referenced as the business model but this can be
especially confusing to non IT staff; this is because the business thinks of
the business model from a different context. Reasons
for a Domain Centric Software Architecture are: 1. Engineers can focus on understanding the
problem/solution space with less concern for technological detail and drive
the software construction process towards delivery of a usable product in the
shortest time possible. 2. Because the software development process is more
efficient when engineers can specialize, i.e., vertical and horizontal
layering. 3. Technology changes at a different rate from that of
the business logic. 4. When implementation technologies are added to a
prototype of a seemingly complete product we do not pollute the solution
space, i.e., in reference to applications built using a transparent
persistence layer. Event
System Driven Construct
the domain model as a singleton having its own event system (an event buss);
an event driven domain model. Observers then register to receive attribute,
collection, and action changes. In addition to the decoupling achieved
through layering this further decouples the domain model from the software
structure it lives in. Business logic can be completely decoupled from other
types of logic and the different rates of change are more easily managed. Remote
Event Notification If the
software structure represents a participant in an enterprise solution then
the domain model can be plugged into an ESB (Enterprise Service Buss) through
the use of handlers that observe the domain model. These handlers then adapt
the domain model events for transport across the ESB. Metadata The
goal here is to build a common API through which data is represented
independent of technology. With this approach a programmer can see no difference
in an asset stored in a database and the same asset stored in an xml file,
properties file, or other form. Have
methods for setting and getting, using key-value pairs, attributes and
collections. This is yet another decoupling mechanism that allows the
business architecture to exist within the technology architecture without
being polluted. This
also helps establish an enterprise wide asset distributed protocol. Metadata
Example (persistence to domain binding) To
understand the power of combining metadata with other decoupling mechanisms
(in this case layering) imagine a persistence layer that is partially
transparent to the domain model and completely transparent to the UI. Using
the “Observer Pattern” the persistence layer will register to receive events
from the domain model. The
domain model objects must contain signatures for loading and saving data.
These signatures must contain at least one parameter for passing data using a
metadata object. The persistence layer is the only user of these methods. Now
the persistence layer listens for load and save events from the domain model
and manipulates data in the model (load events) or persistence (save events). Here
the “persistence to domain layer binding” has been decoupled so that changes
to attributes have no effect on the binding mechanism. In
other words, change to the model and persistence is conducted independently
and there is no side effect of having to change the method signatures that
connect the two layers. And
because persistence has been captured in its own layer it’s possible to
change out the under database technology without any change to the domain
layer. Persistence
Layer Persistence
is where we map data to/from the domain model and long-term storage. In
most cases this means connection to a relational database but it could be a
flat file, XML file, Java Serialized file, CSV file, or other. By
encapsulating persistence in its own layer of functionality it could even be
implemented as a remote interface to a distributed system instead of directly
talking to an underlying storage device, and from the domain model’s
perspective this would be transparent. All
long-term storage logic is to exist in this layer and cannot be accessed by
any other layer than the domain model. The
most important thing here is that we do not allow presentation layer experts
to concern themselves with persistence of the data, i.e., they must interact
with the domain layer. For UI
developers this means they are free to work closely with the users and
interact with the domain layer independent of any concern for persistence. Persistence
is the job of a software engineer proficient in long term storage of data and
not necessarily good at human to machine interaction. A very
helpful trick in Java that removes the need for a relational database and
promotes a RAD process is to use Java File Serialization; it can greatly
compress schedules in the first few RC’s of a product. Summary Up to
this point, layers have been the focus however the architecture presented
here easily scales to a layered and sectioned architecture. Sections
are the breakout of a layer(s) into areas of functionality that are loosely
coupled and highly cohesive. Quite
often a section is reflected and travels vertically across the other layers.
And since this is a domain centric architecture this will begin with the
business architecture. For
larger and more complex projects this allows for vertical and horizontal
slicing of units of work that are more easily managed across engineers. In a
distributed system this architecture is the blue print to each node in a
system while at a higher level a separate architecture will describe the
interaction of nodes as a system of applications that collaborate. This
document is part of a series of documents that together describe a technical
framework for successfully architecting enterprise systems. For
more information see http://architecture.waltdavis.net. References Architectural layer. (2007, June 3). In Wikipedia, The Free
Encyclopedia. Retrieved Business architecture. (2007, October 19). In Wikipedia, The
Free Encyclopedia. Retrieved Business object (computer science). (2007, September 10). In Wikipedia,
The Free Encyclopedia. Retrieved Design Patterns. (2007, November 4). In Wikipedia, The Free
Encyclopedia. Retrieved Domain Driven Design. (2007, October 21). Retrieved Domain model. (2007, October 29). In Wikipedia, The Free
Encyclopedia. Retrieved Event Driven Programming. (2007, November 2). In Wikipedia,
The Free Encyclopedia. Retrieved Metamodeling. (2007, September 7). In Wikipedia, The Free
Encyclopedia. Retrieved Model View Controller. (2007, November 5). In Wikipedia, The
Free Encyclopedia. Retrieved Object Oriented analysis and design. (2007, October 24). In Wikipedia,
The Free Encyclopedia. Retrieved Patterns of Enterprise Application Architecture. (2007, August
1). From Martin Fowler. Retrieved Responsibility Driven Design. (2007, August 31). From Wirfs-Brock Associates. Retrieved Service Oriented architecture. (2007, November 5). In Wikipedia,
The Free Encyclopedia. Retrieved Singleton pattern. (2007, November 1). In Wikipedia, The Free
Encyclopedia. Retrieved Software architecture. (2007, October 25). In Wikipedia, The
Free Encyclopedia. Retrieved Use case. (2007, November 5). In Wikipedia, The Free
Encyclopedia. Retrieved About
The Author Fore
more information or to request training please contact Walt Davis (info@waltdavis.net) Phone: 971.222.3737 www.WalterLeeTech.com Walt
Davis |
© Copyright Walt Davis, all rights reserved.