Software Reality
Programming with
a dose of satire.

Site Map Search


Agile Development
 
Extreme Programming
 
Code Generation


Articles
Lifecycle
Design
Programming
Soapbox
Reviews
Cthulhu

Check out our ageing Reviews Section


Use Case Driven
Use Case Driven Object Modeling with UML: Theory and Practice
Get from use cases to working, maintainable source code. Examples use Spring Framework, JUnit and Enterprise Architect

Agile UML
Agile Development with ICONIX Process
A practical subset of agile development techniques, illustrated by example

Get Controversial!
Extreme Programming Refactored
Extreme Programming with a dose of satire
Available now:



ICONIX/Sparx Public Classes to Come to London

ICONIX is planning a series of open- enrollment public classes entitled Hands-On Enterprise Architect for Power Users in collaboration with Sparx Systems.




Design

Domain-Oriented Architecture:
Separating The Business Interface from the Implementation

By Robin Sharp
June 23, 2002

This is the fourth part of a series of articles on component oriented languages from a Java perspective.

In earlier articles, component oriented languages were described as more evolved languages than object oriented languages. The principle reason being that component oriented languages formally separate type (data) from modules (architecture), and messages (interfaces) from methods (implementation). The premise upon which the evolutionary claim is made is that component oriented languages are closer to expressing the problem than object oriented languages.

In the final section of the last article, the concept of domain oriented languages was introduced. Domain oriented languages allow a domain to be expressed directly, including domain data, architecture and function. These languages can then compile into a working application. The idea of expressing a domain then creating a working application from that expression is not new; it was the basis of 4GL's, such as PowerBuilder. Domain oriented languages have important differences from component oriented languages which will be described below.

From a domain oriented perspective, data and architecture interfaces represent the domain model. From a component oriented perspective, data and architecture interfaces make no distinction between domain and technology, and there is no question of them being technology neutral. From a domain oriented perspective those interfaces can be implemented using different technologies, but should not expose them. For example a domain oriented architecture may expose generic findBy, save and remove mothods but they would not expose their implementation (e.g. EJBExceptions or EJBObject super class).

Domain oriented languages can be described as:

Separating the domain interfaces from their technical implementation

Domain oriented lanaguges rely heavily on code automation techniques, such as code generators, interpreters, proxies or compilers to create the technical implementation. When a domain oriented application is created, a programmer should be able to choose which particular technical implementation is going to implement the business interfaces. For example by choosing a JDBC or EJB option a different implementation of the interfaces would be created. This means that a programmer
can choose different architectural implementations for different situations.

When a project starts off, the programmer may wish to create an in memory or file based architectural implementation; later as the project develops a JDO or EJB architecture could be code automated.

Separating business interfaces from technical implementations means that a domain oriented system can be separated into domain data, architecture and function and technical data, architecture and function. Importantly data and architecture domain interfaces and technical implementation of these interfaces can be code automated. Domain function cannot be code automated and a policy
is required to integrate this into the compiled system.

Code automating an application from a domain expression (data, architecture and function) is immensively powerful. Key to this power is an understanding of software efficiency. Software efficiency is a key aspect to measuring the quality of any domain oriented language. Software efficiency measures the ratio between domain expression and code size. Code efficiency can be dramatically increased by using code automation.

Most programmers are not conscious of code efficiency when programming, but when a code automator is brought into the equation it can be measured. The simplest and most common inefficency is when variables are present that achieve the same generic function.

Code automation is driven by meta data. Java itself does not have sufficent meta data even in its feature descriptors to drive a code automation tool. A combination of Feature Descriptors and JDBC meta data could be used to provide some meta data, but it makes for a truly awful bodge, and would still need to be supplemented. For example EJB requires that column names be specified in alphabetical order. So once you've established the principle that supplementary meta data is required, it's best do to a good job in the first place.

For example a fragment of an Address table in a domain model can be expressed as follows:

  CREATE TABLE
  (
    ...
    line1 VARCHAR(30) NOT NULL
    line2 VARCHAR(30) NOT NULL
    line3 VARCHAR(30) NOT NULL
    ...
  )

In the code the variables line1, line2 and line3 appear in numerous places, each achieving the same generic function. For example in the Address data interface as a get and set method:

  /**
   * @param line1 of the address
   */
  public void setLine1( String line1 ) throws ValidationException;
  
  /**
   * @return String line1 of the address
   */
  public String getLine1() throws ValidationException;

In these examples the property line1 appears 5 times, and we haven't even got to the implementation. If this method is fully implemented to handle empty string values, recursive setting, validation and property events, there is an efficiency level of 15.

  protected String line1;
 
  /**
   * @see com.javelin.furniture.Address#setLine1( java.lang.String line1 )
   */
  public void setLine1( String line1 ) throws ValidationException
  {
     if( line1 != null && line1.length() == 0 ) line1 = null;
 
     if( AbstractBean.isEqual( this.line1, line1 ) ) return;
	 
     if( isValidated() ) getValidator().validateLine1( line1, this, "line1" );
	 
     firePropertyChange( "line1", this.line1, this.line1 = line1 );
  }

In addition to this the line1 property can be specified in the following places:

  •  UI Setting values
  •  UI Getting Values
  •  Validation rules
  •  Data Loading
  •  Data Creation
  •  Data Updates
  •  Data Binding
  •  XML
  •  Messages
  •  Data base definitions.
In other words, enterprise applications operate at an efficiency level in the regions well above an order of magnitude. In our experience of Northwind, creating an optimized EJB produces 100 times as much code as the domain meta data. We were quite shocked by this, especially because it was very difficult to make any code redundant without sacrificing type safety.

The example above shows domain oriented data. The architecture could also be domain oriented. For example an AddressSession class:

  public class AddressSession
  {
    public void save( Address address )
        throws CreateException, StoreException, ValidationException;
 
    public void remove( Address address )
        throws RemoveException, ValidationException;
 
    public Address findByPrimaryKey( Object primaryKey )
        throws FinderException, ValidationException;
 
    public Address[] findByPostCode( String postCode )
        throws FinderException, ValidationException;
  }

The EJB version of this class would be the AddessHome or an AddessSession facade. The AddressHome class would extend the EJBObject and the methods would expose EJBExceptions so whilst the AddressHome interface would be a candidate for component oriented software they would not be a candidate for domain oriented software - because the interfaces expose the implementation.

A good example of a component that would fit into a domain oriented architecture is the jdbc.RowSet. Whilst this is an architectural interface, from its point of view its business end is technology. The RowSet does not expose its own (vendor specific) implementation. The benefit for us is that the RowSet can be implemented in a number of different ways - either directly ontop of a ResultSet or as an In-Memory cache.

The use of Beans and EJB standards has helped to clarify the difference between the business data (beans) and the business architecture (homes and session), as well as technical data and technical architecture. The importance that Beans and EJB standards have legitimised the expression of business domains in interfaces; even if not perfectly.

Having said that developers are increasing criticising Javasoft and Microsoft application servers is because their designers have failed to make the distinction between technical and business programming. Whilst EJB and JTS are admirable for separating data from architecture and expressing business interfaces on the architecture, their complete failure to separate business interfaces from technical implementation can only be interpreted as evolutionary dead-ends. JDO has done slightly better but has its thinking in the same camp as EJB and JTS.

Many of the arguments between the genre of products such as EJB and JTS have been about technical details. There has been very little argument about how easy it is to express particular business domains and produce quality working solutions using different technologies.

To create a decent EJB or MTS system the programmer must be both a business and a technical expert. The quality of their solution is inevitably going to suffer as they must learn and keep up with the ever changing demands of the business and the technology.

To adapt Sun and Microsoft must make a huge break with their current thinking patterns and distinguish between expressing a business model and implementing it using a particular technology. The gulf between implementation programmers and business programmers should have been growing steadily over the few years. The reality is that they have been merging to meet solutions poorly conceived by technologists.

Most of the literature today confuses business architecture with technical architecture. The best architectures represent business interfaces, and technical architectures can come and go. This was the lesson of relational databases that the data model for a business will out live the implementations. Domain oriented programming also takes this lesson on board by creating business architectures based on type and module interfaces then code automating architectural implementations transparently.

With the current emphasis on return on investment (ROI) this is a direction many application architects are now looking because it allow the technology to change without throwing away the code base.

At Javelin Software, the JGenerator tool is a good example of a domain oriented tool that enables a domain model to be generated out to Memory, File, JDBC, JDO or EJB. This is done transparently and the programmer can choose to change implementations at compile time. To the uneducated JGenerator looks like many other object relational mapping tools. Its difference lies an understanding that it is actually a domain oriented language. The potency of the tool means that complete applications can be rendered very quickly once the business domain is well understood.

Currently JGenerator generates the code, as a massive pre-compiler for Java. In future domain oriented languages would skip the pre-compilation step out, however the principles identical.

Domain oriented languages represent a significant advance over component oriented languages, which in turn represent an advance over their more primitive object oriented cousins.

Next time you begin architecting a new software solution think about the 4 principles:

From component oriented languages

(1) Separate the interfaces from the implementation
(2) Separate the types (data) from the modules (architecture)

From domain oriented languages

(3) Separate business interface and technical implementation
(4) Automate architecture, data and source code

In the near future I'll describe a meta data system for Java.

 


Related Articles:

Programming Language Lifecycles

Component Oriented Software - Java Perspectives

Component Oriented Thinking: Separating Data From Architecture

Automated Code Generation: The Fastest Way to Write Software?

 

 

<< Back to Design

<< Back to Software Reality

All trademarks and copyrights on this page are owned by their respective owners.
Stories and articles are owned by the original author.
All the rest Copyright 1998 onwards Matt Stephens. ALL RIGHTS RESERVED.