Enterprise Architecture Part 3

~ Walt Davis (Software Architect) ~

Linked In Profile

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.


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.


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.


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.


Architectural layer. (2007, June 3). In Wikipedia, The Free Encyclopedia. Retrieved 02:47, November 6, 2007, from http://en.wikipedia.org/w/index.php?title=Architectural_layer&oldid=135657204.


Business architecture. (2007, October 19). In Wikipedia, The Free Encyclopedia. Retrieved 02:48, November 6, 2007, from http://en.wikipedia.org/w/index.php?title=Business_architecture&oldid=165567806.


Business object (computer science). (2007, September 10). In Wikipedia, The Free Encyclopedia. Retrieved 04:41, November 6, 2007, from http://en.wikipedia.org/w/index.php?title=Business_object_%28computer_science%29&oldid=157013521.


Design Patterns. (2007, November 4). In Wikipedia, The Free Encyclopedia. Retrieved 04:33, November 6, 2007, from http://en.wikipedia.org/w/index.php?title=Design_Patterns&oldid=169064593.


Domain Driven Design. (2007, October 21). Retrieved 01:48, November 6, 2007, from http://domaindrivendesign.org/.


Domain model. (2007, October 29). In Wikipedia, The Free Encyclopedia. Retrieved 02:48, November 6, 2007, from http://en.wikipedia.org/w/index.php?title=Domain_model&oldid=167800177.


Event Driven Programming. (2007, November 2). In Wikipedia, The Free Encyclopedia. Retrieved 03:47, November 6, 2007, from http://en.wikipedia.org/w/index.php?title=Event-driven_programming&oldid=168714125.


Metamodeling. (2007, September 7). In Wikipedia, The Free Encyclopedia. Retrieved 01:22, November 9, 2007, from http://en.wikipedia.org/w/index.php?title=Metamodeling&oldid=156359022.


Model View Controller. (2007, November 5). In Wikipedia, The Free Encyclopedia. Retrieved 02:47, November 6, 2007, from EnterpriseApplicationArchitecturePart3_files.


Object Oriented analysis and design. (2007, October 24). In Wikipedia, The Free Encyclopedia. Retrieved 03:32, November 6, 2007, from http://en.wikipedia.org/w/index.php?title=Object-oriented_analysis_and_design&oldid=166686514.


Patterns of Enterprise Application Architecture. (2007, August 1). From Martin Fowler. Retrieved 02:49, November 5, 2007, from http://martinfowler.com/books.html.


Responsibility Driven Design. (2007, August 31). From Wirfs-Brock Associates. Retrieved 03:49, November 5, 2007, from http://www.wirfs-brock.com/Design.html.


Service Oriented architecture. (2007, November 5). In Wikipedia, The Free Encyclopedia. Retrieved 04:12, November 6, 2007, from http://en.wikipedia.org/w/index.php?title=Service-oriented_architecture&oldid=169394182.


Singleton pattern. (2007, November 1). In Wikipedia, The Free Encyclopedia. Retrieved 04:16, November 6, 2007, from http://en.wikipedia.org/w/index.php?title=Singleton_pattern&oldid=168593758.


Software architecture. (2007, October 25). In Wikipedia, The Free Encyclopedia. Retrieved 04:13, November 6, 2007, from http://en.wikipedia.org/w/index.php?title=Software_architecture&oldid=166998952.


Use case. (2007, November 5). In Wikipedia, The Free Encyclopedia. Retrieved 02:44, November 6, 2007, from http://en.wikipedia.org/w/index.php?title=Use_case&oldid=169362048.

About The Author

Fore more information or to request training please contact Walt Davis (info@waltdavis.net) Phone: 971.222.3737


Walt Davis
Software Systems Architect

© Copyright Walt Davis, all rights reserved.