Introduction

The primary purpose of most software projects is to add value to the customer’s business. This is done by abstracting the complex web of thoughts inside a human mind in the form of a software program. Most software projects cater to a particular domain, and in many software projects, the domain of a software project is not technical. Unfortunately, majority of the technical people do not give enough importance to the domain of the software, and hence, they lack the required domain knowledge. This lack of domain knowledge leads to a situation where What(to do?) takes over Why(to do?). Generally, in such a scenario, it might be possible to deliver a usable product, but the primary purpose of adding business value is often neglected.

The above mentioned situation is quite common and there is a continual influx of thoughts, which intend to provide a solution, by various experts. Eric Evans is one of such experts, who based on his experience, gained by working on complex projects, epitomized his findings in the form of tips, suggestions, patterns and guidelines, and coined a term Domain Driven Design, better known as DDD. In this blog, I intend to present various aspects of DDD and how it suggests to tackle the complexity of the domain.

What is DDD?

A picture is worth a thousand words and, sometimes, is better suited to convey a message. Similarly, a domain model is a simplification of the domain of the software and it abstracts the elements of domain which are relevant to the problem the software intends to solve. A domain model is representation agnostic, i.e., it can be represented as an UML diagram, as written code, as simply plain English, or as a simple diagram. The decision to choose an option depends upon the situation and complexity of the problem. The process of creating, maintaining and enhancing highly expressive domain model by applying objected oriented principles, design patterns is known as Domain Driven Design(DDD). One important point to understand is that DDD is not a one time activity. It is an iterative process and model evolves with the project.

We all know that the process of creating domain model by abstracting from the complexities of a domain is not an easy job. Experienced programmers/thought leaders often compare this job with that of an artist. Few would disagree with them. But, with any art, there are certain principles and practices, which make the process of identifying and representing abstractions simpler. DDD also suggests to employ certain principles and practices, which we may already be doing intuitively, to work with highly expressive domain models. Let’s have a look at some of the principles and practices of DDD.

Getting Started with DDD
There might be several questions, which may be taking shape in the mind right now. Let’s see which DDD principles and practices applies to specific question

Q: I don’t have the domain knowledge. How will I communicate effectively with the domain experts?
A: In most projects, there is an interface between the technical people and the domain experts. We may call this expert a Business Analyst, a Product Owner, or with some other name. Sometimes, this interface is not effective to transform the messages between two parties and in the process of message transformation, some relevant details are missed. This leads to a situation where WHAT takes over WHY.

To overcome this problem, DDD emphasizes to have a close relationship between the domain experts and the developers. Even when a modeler is working with domain experts(DE), he should be hands-on enough to think about design issues while brainstorming with the DE. DDD also suggests DDD developers to pick up key concepts while having conversation with the DE and also educate them about their terminology. This leads to the development of a Ubiquitous Language(UL) which forms the basis of development domain model. UL is basically a medium of communication which is used to develop a domain model. It is also used to validate a domain model periodically. The development of UL is an iterative process and is based on mutual agreement between DE and technical people.

Q: How will I represent my domain model?
A: Domain model should be represented in a way which best communicates the intent of the domain knowledge. It can be in the form of a diagram, a UML diagram, plain English, or simply code. Now, when there is freedom to represent something in multiple forms, how to maintain the sanctity of the domain model. I think that’s the job of the skilled developers or domain modelers. It is difficult to provide a rule for everything and we all know that real world is like that. Sometimes we have to break the rules and take pragmatic decisions. DDD realizes that and promotes developers to take pragmatic decisions instead of being bound by the rules.

Q: How will I layout the architecture of the application with DDD?
A: The focus of DDD is to create domain models that are rich in behavior. Typically, an application has several other issues as well which are not concerned with the domain. To work effectively with DDD, we need to isolate those issues from the domain modelling. In order to do so, we can use layered architecture to isolate and group the problems.

In a layered architecture, each layer is aware of the layers below it. In general, a layer at the lower level cannot make calls to the layer above it.

Q: How will I represent concepts in a domain model?
A: Most concepts in domain can be classified into

• Something which has an identity: Entities. Entities, which are essentially objects, identified by an identity, which does not change. The identity can be a surrogate key or a composite key.
• Something which has an important meaning in larger picture but does not have an identity of it’s own: Value Objects(VOs). VOs represent meaningful concepts and abstracts the details of those concepts but does not have their own entity. For example, a phone number is one such thing, which represent certain information, but does not make any sense if not associated with a person, place, etc.
• Something which relate various concepts with each other: Cardinality. Cardinality represents relationship between various entities. DDD advocates to have minimum cardinality between entities.
• Behavior common to various concepts: Services. Services are components which provides behavior which is not specific any particular entity. These services are different from the application service, in that, they provide services to the domain layer and not callable from the application layer.

Apart from the above, DDD also introduces the concept of Aggregates, which are essentially small group of related objects. Aggregates have a common root and act as an entry point for outer world to the constituents of the aggregate. This helps in managing the complex web of associations in a domain model.

Also, since in many cases, entities will be persisted and again constructed back, DDD advocates the use of Factories and Repositories. Factories are generally used to create complex objects and Repositories are used to reconstruct an already persisted object. Here, Factories is not something which refers to only Factory pattern. We are free to choose from Factory, Builder or any other that we are aware of based on our judgement and something which conforms to UL.

Q: How will I model behavior in domain model?
A: In domain modelling, majorly, we have following kinds of behavior

• One which validates the domain model against certain rules: Specification Pattern. Specification pattern is employed to validate domain model against certain rule. For example, The logic to check whether the project is overdue can be put in the Project object, as in the following listing

class Project {
  public boolean isOverdue() { … }
}

or, it can be abstracted as a Specification, as shown in the following code

public interface ProjectSpecification {
  public boolean isSatisfiedBy(Project p);
}
public class ProjectIsOverdueSpecification implements ProjectSpecification {
  public boolean isSatisfiedBy(Project p) { … }
}
If (projectIsOverdueSpecification.isSatisfiedBy(theCurrentProject) { … }

• One which is algorithmic in nature, like calculations, rules: Strategy/Policy Pattern. Strategy pattern is essentially employed to abstract out algorithms or business rules out of domain model. For example, if there is a business rule to allow Voyage overloading with 10% overloading. Then, without strategy pattern, code might look like

   public int makeBooking(Cargo cargo, Voyage voyage) {
     double maxBooking = voyage.capacity() * 1.1;
     if ((voyage.bookedCargoSize() + cargo.size()) > maxBooking)
         return –1;
     int confirmation = orderConfirmationSequence.next();
     voyage.addCargo(cargo, confirmation);
     return confirmation;
  }
          

  After applying Strategy pattern, the code might look like

  public int makeBooking(Cargo cargo, Voyage voyage) {
  if (!overbookingPolicy.isAllowed(cargo, voyage)) return –1;
     int confirmation = orderConfirmationSequence.next();
     voyage.addCargo(cargo, confirmation);
     return confirmation;
  }
  
  public OverBookingPolicy {
  public boolean isAllowed(Cargo cargo, Voyage voyage) {
     return (cargo.size() + voyage.bookedCargoSize()) <=
           (voyage.capacity() * 1.1);
  }
  }
          

  This helps in making code/model more expressive and flexible.

Q: How will I maintain the integrity of the model in a large team with complex domain?
A: While working on large projects and large teams, it is difficult to express the intent of the domain with a single model. DDD advocates the use separate models to model the entire system. The patterns to handle the complexity of working with separate models and communicating between them are grouped as Strategic Design Patterns in DDD. Various strategic design patterns are their relationships are shown in the following diagram.

• Bounded Context: DDD suggests to separate multiple domain models based on contexts. For example, in above figure domain model expressing project model is bound by project context, where as, billing model is bound by billing context. Contexts are generally created based on team structure and domain concepts.
• Context Maps: Different models in an application cannot work in isolation. There will be some data sharing among them. DDD provides some patterns based on experience. Theses pattens have specific applicability which are explained below.
  • Shared Kernel: In this pattern, another domain model is created which models the shared data. For example, in the above example, shared data can be Customer and that would be part of Shared Kernel.
  • Customer/Supplier: This pattern is applied when one context has dependency on another pattern. In this scenario, customers models can discuss their concerns with suppliers and raise their concerns and get the supplier model modified.
  • Conformist: This pattern is similar to above pattern but customer model has no control over supplier model and customers are forced to deal with whatever suppliers dish out.
  • Anti Corruption(AC) Layer: When the supplier model is third party and legacy code, there is high probability that the legacy code is developed not using domain modelling techniques. There might be chance of theses bad practices to creep into your own domain model. To insulate your domain model, DDD advocates the use of an AC layer, which is essentially a collection of services and adapters which translate the communication between the two models.
  • Separate Ways: When the cost of integration between various model becomes overwhelming, we can decide not to integrate them at all. Instead, we can decide to break the application into smaller application which have little or nothing in common from modeling perspective.

Q: How do I learn more about DDD?
A: To get started with DDD, I recommend following approach

1. Download Domain Driven Design Quickly, a brief and concise guide about DDD from InfoQ to get started.
2. Go through, Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans.
3. You can also join Domain driven design group on Yahoo to get connected with the latest in DDD.

Conclusion
In this blog, we discussed about what is DDD and looked at the various pattens suggested by DDD. DDD is not only object orientation done right but also understanding the domain of the application. DDD does not lay down any rules and only suggests to do certain things, which have worked on various projects. Any developer can benefit from it because it is merely a thought process which has evolved based on experience and not is not a figment of anyone’s imagination. DDD, along with Agile practices like TDD, Continuous Integration and Refactoring, is a potent weapon in any designer’s armor.

As promising it may be, DDD’s applicability has major challenges. Based on my experience in IT industry, I have summarized majority of them below:

• Poor quality of requirements: As already discussed in the blog, most projects have a translation layer which translates the requirements between business and technical people. Some may call them Business Analysts, whereas some call them Product Owner. So, quality of communication, and hence the requirements, depend upon this translation layer. On top of that, if this translation layer is bureaucratic, they would not like developers to work directly with the business as it would dilute their role in the project. So, apart from skills, DDD requires people with right mindset at the top and the team.
• Simple Domain: The application/domain may be simple enough to yield any significant ROI of using DDD. The effect of DDD might be visible once the project becomes complex.
• Motivation: DDD is all about making pragmatic decisions and it requires a lot of skill, but more importantly, a lot of motivation to make those decisions.

In summary, DDD is a promising concept, which is gaining momentum in recent years. Although, it may not be applicable to every project directly, but learning these principles would certainly enhance design skills of a developer.

One of my colleague asked me if I can share some resources on patterns. That got me thinking what to share! Then in casual talk I just shared him some links. But then there was nothing about MVC or MVP or MVVM or any UX patterns. I thought that should be more organized. So here it is. There are

• Design Patterns
• Architectural Patterns
• UX Patterns

Design Patterns

Design patterns as we know of from the Gang of Four are pretty old [very relevant too] and every now and them evolved versions of these basic design patterns have emerged.

The extended list is available in Wikipedia at http://en.wikipedia.org/wiki/Design_pattern_(computer_science) 

Also check out the best resource on web on Design patterns with examples and explanation at http://www.dofactory.com/Patterns/Patterns.aspx

Architectural Patterns

Then there are Architectural Design Patterns also detailed in Wikipedia at http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science) which offer well-established solutions to architectural problems in software engineering. I would like to add MVP and MVVM to the list. Easy to understand explanation of MVC, MVP and MVVM can be found at http://nirajrules.wordpress.com/2009/07/18/mvc-vs-mvp-vs-mvvm/

UX Patterns

Apart from the Design/Architectural patterns, there is a User experience patterns. Infragistics has nicely put a list of 91 UX patterns that are clubbed by user tasks, tag relations, and by wireframe. Find all of them at  Quince http://quince.infragistics.com/

There are some coding patterns blog by GABE MOOTHART. May be he can come up with proper list/table of contents for all the patterns he is talking about.

If I have missed out comment.. I will update the post!

If you don’t customize your schemas with JAXB, your generated classes will not handle correctly the list in your UI (using beans binding functionnality).

If you have lists in your xml, you’ll probably handle them with Jtable or JList in your UI. Modifications of objects (from the edition form if you don’t edit directly in your list) will be seen in your table, but creation or deletion of an element in the list will not be seen. To see creation or deletion events in your UI lists, your object list have to be observable, i.e. implements ObservableList.

JAXB generate the following code for xml lists :

protected List<E> listElements = new ArrayList<E>();

The way to create an an observable list is below; beans binding library contains a factory :

org.jdesktop.observablecollections.ObservableCollections.observableList(new ArrayList<E>());

I would appreciate a way to modify the creation method in JAXB, but didn’t find it. So I created a class which implements the ObservableList interface (with an almost Decorator Pattern) and specify to JAXB to use this class to handle lists :

So, first step, create your own class for lists, that implements all method of ObservableList :

package my.package;

import java.util.ArrayList;
import java.util.Collection;
import java.util.Iterator;
import java.util.List;
import java.util.ListIterator;

import org.jdesktop.observablecollections.ObservableCollections;
import org.jdesktop.observablecollections.ObservableList;
import org.jdesktop.observablecollections.ObservableListListener;

public class MyObservableList<E> implements
		ObservableList<E> {

	private ObservableList<E> l= ObservableCollections.observableList(new ArrayList<E>());

	public AdretObservableList() {

	}

	public void addObservableListListener(ObservableListListener arg0) {
		l.addObservableListListener(arg0);
	}

	public void removeObservableListListener(ObservableListListener arg0) {
		l.removeObservableListListener(arg0);
	}

//... and so one for all methods
}

Then specify xjc to use a custom bindings settings. Use -b file.xjb, the file containing the following instructions :

<bindings xmlns="http://java.sun.com/xml/ns/jaxb" version="2.0" xmlns:xs="http://www.w3.org/2001/XMLSchema">

  <globalBindings
  collectionType="my.package.MyObservableList" >
  </globalBindings>

</bindings>

This way, JAXB will call

protected List<E> listElements = new MyObservableList<E>();

The plugin from no0ne handle this UI requirement (with the library CollectionBeanProperty).

Inizieranno ora una serie di articoli specifici sui Pattern di tipo Creational, in particolare analizzeremo:

• Abstract Factory
• Builder
• Factory Method
• Prototype
• Singleton

Prima di entrare nella analisi approfondita di questi strumenti è utile volgere uno sguardo d’insieme verso l’ambito di applicazione degli stessi.

I Pattern di tipo creational astraggono il processo di instanziazione, in sostanza aiutano a creare un sistema indipendente rispetto a come gli oggetti che lo compongono vengono creati, composti e rappresentati.

Questa categoria di pattern diviene fondamentale durante la fase di evoluzione del sistema nel caso in cui questo dipenda più dalla composizione degli oggetti che dalla ereditarietà delle classi.

Esistono due temi ricorrenti in questi pattern:

1. incapsulano tutta la conoscenza all’interno di classi concerete che il sistema utilizza
2. nascondono come le istanze delle classi vengono generate

Durante l’analisi dei pattern Creazionali analizzeremo un problema concreto lato applicativo, ovvero la costruzione di un labirinto per un videogioco.

Le caratteristiche principali dell’applicazione saranno:

• Stanze (Room)
• Muri (Wall)
• Porte (Door)

Tutte classi che descrivono le medesime strutture

In più avremo la presenza della classe MapSite, una classe astratta che gestisce tutti i componenti di un labirinto (Room, Wall, Door) e la classe Maze che rappresenta una collezione di stanze.

Esiste una classe ulteriore MazeGame che avrà il compito di creare il labirinto, in particolare genererà:

• Labirnito
• stanze
• porte di comunicazione fra stanze
• etc…

Esaminiamo ora a grandi linee come l’utilizzo dei Design Pattern di tipo creazionale ci può aiutare nella progettazione di questo videogioco.

Innanzitutto è utile sottolineare che i pattern di questa sezione non servono a rendere la struttura più semplice, ma più flessibile, ovvero render più semplice il cambiamento delle classi che definiscono la struttura del un labirinto.

I dettagli:

• Se la classe CreateMaze utilizzasse delle funzioni virtuali per creare stanze, muri e porte invece di utilizzare dei costruttori, allora si potrebbero modificare le stesse classi perchè vengano instanziate creando una sottoclasse (MazeGame) che ne ridefinisca le funzioni. Questo è un esempio di Factory Method
• Se CreateMaze passasse un oggetto come parametro utilizzabile per la creazione di stanze, muri e porte, allora sarebbe possibile cambiare il comportamento delle classi che definiscono porte, muri e stanze semplicemente passandogli parametri differenti. Absreact Factory
• Se CreateMaze passasse un oggetto come parametro utilizzabile per creare un nuovo labirinto nella sua interezza, utilizzando le operazioni per aggiungere muri, porte e stanze, allora si potrebbe utilizzare l’ereditarietà per modificare una parte del labirinto o il modo in cui questo viene costruito. Builder
• Se CreateMaze fosse parametrizzato da vari prototipi di stanze, porte e muri, i quali si accopiano e si aggiungono al labirinto stesso, sarebbe possibile cambiare la composizione del labirinto cambiando questi prototipi con altri. Prototype
• Singleton protebbe assicurare che solo un labirinto per gioco sia accessibile, e così anche per tutti gli altri oggetti che compongono il gioco, senza fare riferiemnto a variabili o funzioni globali.

Today I’m just enough in the mood to write some stuff…wish this mood would last for a few more days

Ok. What’s this time? I forgot to mention I’ll be speaking at SLODUG meeting at Wednesday 3.12.2009 too. This session we’ll cover:

MVVM:

• What is MVVM
• How we use it
• Pros & cons

WPF Composite

• Framework presentation
• UI Composition
• Modularity
• Commanding
• Eventing
• Pros & cons

Hope you join us!

Hi,

I’m pretty sure all of you know the famous WebCamp. If you don’t, go ahead and inform yourself on the link below.

WebCamp

Notifying you that the WebCamp we’ll get underway at Saturday 28.11.2009 is little to late…but if you’ll be there, make sure you don’t miss my presentation

SL: “Chaos vs Order – uporabimo MVVM v WPF & Silverlight aplikacijah”
EN: “Chaos vs Order – use MVVM in WPF & Silverlight applications”

That’s it

There was an interesting side discussion about the level of control over things like lighting that you might want in an “intelligent environment” at Seth’s proposal.

That was already off topic, and I didn’t want to derail the conversation even further, but it reminded me of the chapter in the original design patterns book* where Chris points out that it’s good to have windows on three sides of a room to avoid harsh contrasts between light and dark. That’s one way to do it, but it’s hard (and expensive) to design a building to meet that constraint, if you want to have natural light in every room; it wouldn’t be hard to have embedded sensors and adjustable lighting fix the problem, though.

What other architectural design patterns can be worked around with a bit of cheap technology? I see a lot of modernist architecture that takes advantage of advances in materials science to create interesting looking structures that would have been impossible centuries ago, and I see some of what I think of as Jane Jacobs style patterns, where classical ideas are used to create comfortable spaces that people actually want to use, but I don’t see much use of cutting edge technology to create really livable space. Why is that, and what can we do about it?

*Christopher Alexendar’s A Pattern Language, not the GoF Design Patterns book

I decided to use Prism, aka Microsoft Composite Application Guidance For WPF and Silverlight.

This is very much like using a supersonic jet fighter to pop down to the local shops but its effective, not very hard and does not require you to write reams of fragile custom code. You just need to spend a bit of time getting used to Prism. Now that’s not a trivial task, but you should have covered the fundamental concepts within a working week, assuming you have some prior knowledge of Dependency Injection.

The huge advantage to you is that Prism is written by people who are much better programmers than you or I are, so the code is robust, whereas writing a custom MDI Window Manager is out of the league of most Intermediate-level developers (most of us).

Very simply, Prism allows the development of Modular Applications in which the User Interface of an application is decomposed into loosely-coupled Modules, each of which occupies a specific area on the screen, known as a Region.

No window (known in Prism as a View) can move outside the Region in which it is contained. This replicates the MDI-like behaviour you’re looking for.

Prism is also a library of Best Practices – it’s produced by the Microsoft Patterns and Practices team – so you get heaps of built-ins for free. And there’s a helpful forum where others using Prism are happy to help us newbies.

You can also have multiple windows (views) open simultaneously if you want, but this will render as a tabbed interface which is not exactly the same as MDI.

I embarked upon this approach and have been successful in producing a MDI-like app. It wasn’t too hard and I learnt heaps along the way. Go for it.

I read a post about MEF vs. IOC which cleared the confusion: MEF should be used external of app, while IOC should be used internally.

Good point. I have been struggling with how to separate my view and view model correctly in WPF app for a long time.   In fact Bil Simer already suggested that MEF is perfect fit in MVVM/Presentation Model last year during the Edmonton Code Camp 2008.

Ideally, all view models can be compiled into a separated assembly and put into specific folder to be imported by UI views!

Some code changes during my code conversion include:

• Remove ctor args from view model, I haven’t figure out how to feed ctor args when MEF importing. This is not easy as auto-wiring in IOC. I ended up with a separate initialize method in each view model, which is not too bad, because I have to call wireUpViewModel from view anyway, this Initialize method has a perfect place to put.
• I’m still not sure where should I put Container.Compose() method, because this method needs the instance the object to be imported into, I think compose as needed is better for WPF app.
• Shared mode is the default behavior for export and import, it messed up my event handling code, (true, I didn’t do -= before +=). I had to explicitly add this everywhere.

[Export]
[PartCreationPolicy(CreationPolicy.NonShared)]
or
[Import(typeof(NewRequestTypeViewModel), RequiredCreationPolicy = CreationPolicy.NonShared)]

Code:

    public partial class TemplateEditShell : Window{

        private CompositionContainer _mefContainer;

        public TemplateEditShell()
        {
            InitializeComponent();
            InitialzieMEF();
        }

        private void InitialzieMEF()
        {
            var catalog = new AssemblyCatalog(System.Reflection.Assembly.GetExecutingAssembly());
            _mefContainer = new CompositionContainer(catalog);
        }

        private void btnEditItemList_Click(object sender, RoutedEventArgs e)
        {
            var proxy = ObjectFactory.GetInstance<IRequestManagementAdminService>();
            var view = new EditRequestTypeItemListView(_viewModel.SelectedRequestType, proxy);
            _mefContainer.ComposeParts(view);
            view.WireUpViewModel();
            view.ShowDialog();
        }
  }

    public partial class EditRequestTypeItemListView : Window
    {
        private readonly RequestTypeDto _requestTypeDto;
        private readonly IRequestManagementAdminService _proxy;

        [Import]
        public IEditRequestTypeItemListViewModel EditRequestTypeItemListViewModel { get; set; }

        public EditRequestTypeItemListView(RequestTypeDto requestTypeDto, IRequestManagementAdminservice proxy)
        {
            _requestTypeDto = requestTypeDto;
            _proxy = proxy;
            InitializeComponent();

            // Can't wire up in ctor, coz MEF import hasn't start/finish yet.
//            WireUpViewModel();
        }

        public void WireUpViewModel()
        {
            DataContext = EditRequestTypeItemListViewModel;

            EditRequestTypeItemListViewModel.Initialize(_proxy, _requestTypeDto);

            EditRequestTypeItemListViewModel.RequestShowMessage += (o, arg) => MessageBox.Show(arg.EventData);

        }
    }

    [Export(typeof(IEditRequestTypeItemListViewModel))]
    public class EditRequestTypeItemListViewModel : ViewModelBase, IEditRequestTypeItemListViewModel
    {
        private IRequestManagementAdminContract _proxy;
        private RequestTypeDto _currentRequestType;

        public RequestTypeItemDto SelectedRequestTypeItem { get; set; }

        public ObservableCollection ItemList { get; set; }

        public EditRequestTypeItemListViewModel()
        {
        }

        public void Initialize(IRequestManagementAdminContract proxy, RequestTypeDto currentRequestType)
        {
            _proxy = proxy;
            _currentRequestType = currentRequestType;

            ItemList = new ObservableCollection(proxy.FindAllRequestTypeItems(currentRequestType.Id));

            SelectedRequestTypeItem = ItemList.FirstOrDefault();
        }
  }

Introduction

Most enterprise applications use Layering as the primary technique to break the complexity of the software projects. Layering involves breaking down the applications in various layers where each layer lie above the other and provide services to the higher layer. Layering provides following benefits

• You can understand about a layer without knowing about other layers. For example, if you know how TCP works you can create your own FTP service without actually knowing about the internals of the ethernet.
• It is easy to substitute the layers with alternative implementation. For example, if DAO layer is designed properly, if should be easy to change the ORM solution from Hibernate to iBatis easily.
• Layering also helps in standardization and extensibility.

But the downsides of layering applications include cascading changes, performance overhead of converting data from one representation into another and it is not often easy to decide the later of a particular component. Considering the benefits of layering and it’s applicability to almost any sort of computer application, it is used widely and successfully.

Three primary layers of an enterprise application can broadly be categorized into

1. Presentation Layer: Information display, HTTP requests, command line invocations, batch API, etc.
2. Domain Layer: Here lies the “Heart of the software”
3. Datasource Layer: Provides access to external resources like databases, messaging, mail server, etc.

In this blog, we will discuss various patterns of organizing domain logic and specific pros and cons of each. We will also discuss how these approaches compare with each other.

Domain Login Patterns
In his book, PoEEA, Martin Fowler has classified domain logic patterns into three primary patterns: Transaction Script, Domain Model and Table Module. He also discussed introducing an additional layer, Service Layer, which is useful in providing horizontal services. Let’s look at each of these in detail.

Transaction Script (TS)
Transaction script is essentially a procedure that takes input from the presentation, processes it with validations and calculations, stores data in the database, send emails, etc. It may also fetch the data and send to the UI. It’s more like coding a C program in Java. Typically, in transaction script method of organizing domain logic, the code is segregated into various services and each service has methods that perform a particular business functionality. A method of a transaction service might look like this

void tsmethod(params) {
   // get data
   // process data
   if () {
   } else if {
   } else {
   }
   // insert/update/delete data
   //send email
}

As you can see from the above, most of the of the above code is procedural. Here, the services act on the entities. A typical example would be an interaction between session bean and entity bean. Another similar pattern not mentioned in the PoEEA is Anemic Domain Model (ADM) which works on the same principle where domain objects have attributes and relationships but does not have behaviour. Behaviour is provided by the services. The different between TS and ADM is that in former we do not have domain objects but rather have something which Fowler describe as Table Data Gateway, which essentially is a wrapper for SQL queries.

Domain Model (DM)
In domain model approach, both behaviour and data are encapsulated inside the domain objects. Domain model looks different from the database design and utilizes inheritance, strategies, and other design patterns to create complex webs of small interconnected objects. A typical domain model code might look like

class Bar {
  private BarAdmissionPolicy = new BarAdmissionPolicy();
  public void admit(Person person) {
     if (BarAdmissionPolicy.isAllowed(person)) {
         this.add(person)
     }
  }
}
public class BarAdmissionPolicy {
   public boolean isAllowed(Person person) {
     if (person.age > 18) {
        return true;
     }
     return false;
   }
}

A well designed domain model provides an abstraction of the domain logic. It encapsulates complex business logic as interactions between domain objects.

Table Module (TM)
It is essentially a singleton instance that handles the business logic for all the rows in a database table. There is no concept of identity in a Table Module. It is designed to operate on entire table data. A typical domain might look like

class Product {
 void insert(name, type, etc) {
 }
 void insertAll(List) {
 }
 void calculateProductCost(List productIds) {
 }
}

As you can see, a table module encapsulates the data and behaviour of the entire table. It is most commonly used in places where UI widgets are data-aware like Oracle Forms or .Net environment which has Visual Studio, which provides tools like RecordSet.

Service Layer (SL)
A Service Layer defines an application’s boundary and its set of available operations from the perspective of interfacing client layers. It encapsulates the application’s business logic, controlling transactions, applying security and coordinating responses in the implementation of its operations. Service Layer can be thick or thin depending upon whether you are using transaction scripts or domain model.

Now, we have understanding of the various domain logic patterns, let’s discuss how they compare with each other.

Comparison
Essentially, if you are using one of DM, TM or ADM pattern, the domain layer can be split into two layers: SL + DM/TM/ADM. SL is essential in providing horizontal services like security, transactions, etc. With TS in practice, it is difficult to identify the difference between SL and TS since TS can double up as a SL also.

Since, TM emphasizes one class per table, there are issues in implementing OO concepts while inheritance. There are no direct relationships between objects. For example, if you want to get a List of Products and Categories separately then it is easy to define where to put the code, but it is not clear where to put the code if you need a RecordSet which contains both Products and Categories.

TS is more like a service class which makes implementing domain logic difficult when the complexity of the application increases, but works well for simple applications.

There is a tough competition between ADM and DM. DM is essentially a Rich Domain Model (RDM). Common things between them includes data and relationships. But things specific to RDM is behaviour of the domain model. There has been a heated debate between designers to prove the dominance of one over the other. Suprisingly, the wiki page for ADM lists why should be avoid them. I reiterate them here

• Logic cannot be implemented in a truly object-oriented way unless wrappers are used, which hide the anemic data structure.
• Violation of the principals information hiding and encapsulation.
• Necessitates a separate business layer to contain the logic otherwise located in a domain model. It also means that domain model’s objects cannot guarantee their correctness at any moment, because their validation and mutation logic is placed somewhere outside (most likely in multiple places).
• Necessitates a global access to internals of shared business entities increasing coupling and fragility.
• Facilitates code duplication among transactional scripts and similar use cases, reduces code reuse.
• Necessitates a service layer when sharing domain logic across differing consumers of an object model.
• Makes a model less expressive and harder to understand.

The difference between ADM and RDM is the focus of control. In the former, the services has the control and in the later domain objects controls the services. It is shown in the following diagram.

Another benefit that differentiates ADM and RDM is that in ADM a developer has to understand two layers, service layer and domain layer but in RDM once you get the grasp of domain model, which is essentially a model of the domain logic, you get a grasp of the business and can work productively to enhance the software. RDM also makes code cohesive.

Experts also advocate to consider maintainability while deciding to choose between various approaches. In his book PoEEA, Fowler explains this with the help of a diagram which is shown below

The source of the above diagram is not known. But, according to this diagram, it takes time to pick up speed with the domain model. Of course, with skilled developers the initial startup time reduces. But, as the complexity of the application increases, it becomes increasingly difficult to maintain the application if it is coded with TS pattern. TM pattern delays the cutoff point where DM takes over, but TM is advocated for .Net environments as Visual Studio provides tools which work well with TM.

Conclusion
In this blog, we discussed various patterns for organizing domain logic in enterprise applications. Clearly, there is no silver bullet which fits all scenarios. Since, we work with object-oriented programming languages, it is advisable to work with approaches like DM to encapsulate business logic. Also, it makes working with complex applications easier as the complexity of the application increases. DM helps in abstracting a model of the real world domain logic in the code which once understood can make working on the applications more productive and fruitful. For simple applications, TS/ADM meets the requirements.

But, how to decide whether the application is complex or easy. Most of the metrics talk about the complexity once the software has been coded by analyzing if-else statements, cyclomatic complexity, etc. But, here, we are talking about predicting complexity, and there is no known metric which can objectively tell that. However, it can be subjectively predicted by knowledge of the domain of the software, which is gained by experience.

Another and most important factor which must be taken into consideration is maintainability. Although it cannot be quantitatively measured, but since we work in to the objective oriented world, DM seems to have an edge over other approaches and it employs inheritance, polymorphism, etc to encapsulate the domain logic.

As a final word, all the above domain model patterns are not mutually exclusive and an understanding of all of above might help us decide an approach for developing a particular software.

My last Agile Revelations post was an unexpected foray into the reasons behind why I love Agile so much. Written on a Friday night, a bit bored, it started me thinking about my career in software development and how I got to this point in my life.

So if you weren’t put off by my previous post and are still interested in what motivates people like me to pursue this most rewarding of methodologies then read on……..

So where was I? Oh yes, I was still in my first development job and I’d just finished reading Extreme Programming: embrace change by Kent Beck – the book which single-handedly inspired me to take on Agile. I’d been in that role for about a year by the time I finished the book and at around the same time I completed my full MCSD in my spare time. And it was lucky because within a month my company had no more C# work for me (they’d decided to re-write in java) so I took a junior C# developer role with a new company.

The development work there was challenging for a relatively in-experienced developer so I found it hard work implementing real WinForms and ASP.Net Web applications into production, but the hardest thing about it was that between projects there was a lot of “sitting around time” where we would be waiting for work (read spec documents as it was a classic waterfall environment!). This was so immensely painful as I hate being bored, having to pester people to give me work to do so in the end I used this time to improve my development skills and learn more about Agile.

The funny thing is that nowadays “being Agile” is such a buzz word and everybody and his dog is claiming that their company is doing it. But at the time it still felt very new (well I guess it was in the UK) and it wasn’t enough to just read buzz word books about XP – I wanted to learn the coding principles behind Agile and understand what made these programmers (apparently) so talented.

So I spent loads of time reading blogs, researching who was saying the most about Agile and XP and (to name but a few) I came up with some very well known writers on these subjects: Martin Fowler, Kent Beck and my own personal God Jeremy Miller.

I quickly realised that an Agile methodogy is useless if you don’t know how to write quality code so I started buying books which concentrated on improving development skills and writing clean code, here are just a few I started out with:

Refactoring by Martin Fowler
Test Driven Development by Kent Beck
POEAA by Martin Fowler
Head first Design Patterns by the Freemans
Applying DDD by Jimmy Nilsson

And that was how I spent my 2nd year in software development. It was an interesting time and for anyone just starting out I would definitely recommend these writers (and obviously a whole load more now – you’ll have to wait for part 3 for those!). The only caveat I would say is that these guys are so good that I did sometimes feel out of my depth, thinking I would never be able to write code as well as them (which is probably still true but I do at least now try!). I think this was probably a very natural reaction but to counter it I would recommend that rather than just reading about the concepts, try to implement them as often as you can in production code. With that said, the best way to ultimately learn is to find an environment with technically excellent, like minded people, eager to learn the same values and able to implement them in production.

Enter uSwitch stage left

Until next time…

This design patterns is all about class instantiation. This pattern can be further divided into class-creation patterns and object-creational patterns. While class-creation patterns use inheritance effectively in the instantiation process, object-creation patterns use delegation effectively to get the job done.

Creational patterns become important as systems evolve to depend more on object composition than class inheritance.

• Abstract Factory

Creates an instance of several families of classes

• Builder

Separates object construction from its representation

• Factory Method

Creates an instance of several derived classes

• Object Pool

Avoid expensive acquisition and release of resources by recycling objects that are no longer in use

• Prototype

A fully initialized instance to be copied or cloned

• Singleton

A class of which only a single instance can exist

Soon I’ll start posting detailed description of each one o these design paters.

Last week, the tech team and I (at Clock Ltd) with the help of  iBuildings, were discussing Design Patterns and OO.

We discussed that in some of the frameworks/projects we had worked on the class or filename was the actual design pattern, for instance Factory.php which contains the class Factory, which seemingly helped readability and understanding of what the class is doing or what it is about.

However! a class may happen to be a singleton, but that’s not its main purpose in life, so I think naming it Singleton is perhaps a bad idea… which then lead me to think that the best way to get this method of readability/understanding across maybe to use the comments…

…perhaps phpdoc should contain a new @pattern tag? (or perhaps phpdoc has another tag that could be utilised for this purpose?)

I think this would be extremely useful for maintenance of code, and understanding of the original authors ideas of the code.

Useful diagram showing relationship between different design patterns from GoF.

I talked about patterns back in July and here I am again talking about them.

Rightly so, why design something that there are already best practices for?

Recap

Design patterns were first described in the 1960s by Christopher Alexander, an architect who noticed that many things in our lives happen according to patterns. He adapted his observations to his work and published many findings on the topic. In User Experience, design pattern refers to a reusable and applicable solution to general real-world problems. For example, a solution for navigating around a website is site navigation (a list of links that point to different sections of the site), a solution for displaying content in a compact space are module tabs. There are many ways to tackle a specific requirement – and as a designer – the most important thing you can do is selecting the option that best reflects the needs of your users.

40+ Helpful Resources On User Interface Design Patterns

There is an article on Smahing Magazine which highlights what it thinks to be the best of the best sites for design patterns. I find myself using this article again and again to reference these sites.

My personal favorites are:

UI-patterns.com
UI-patterns.com is a large collection of design patterns for UI designers to gain inspiration from. The site allows users to keep sets of their own (publicly accessible to site visitors) so that you can see other UI design pattern collections.

Interaction Design Pattern Library
Welie.com has an interaction design pattern library maintained by Martijn van Welie, a Ph. D. graduate in Human Computer Interaction who now works as an Interaction Design Senior Consultant for Philips Design. The library features a ton of design patterns involving various site tasks such as navigating around a site, searching a site, and basic interactions such as slideshows. Each pattern follows a specific format: (1) the problem, (2) the solution, (3) when to use the pattern, (4) why you should use the design pattern, and (5) examples of the pattern in use.

QUINCE: X Patterns Explorer
QUINCE is a beautiful and stunning web application that helps you explore an innumerable amount of user experience design patterns such as date pickers and two-panel selectors. The application requires the Silverlight plugin and is best viewed under Internet Explorer (though we have verified it to work well in Firefox and Safari).

Design of sites

The website is derived from the book and claims to be the definitive reference for the principles, methodologies, and best practices for exceptional Web design.

Designing Web Interfaces

This website is also derived from the book Designing Web Interfaces and lacks detial but has some good stuff on it.

At a very high level and as a first draft, I propose the following classes that will serve as the base for my design:

Investment: positions and portfolios

Investments are at the base of everything: they are the basic unit into which money can be put to work, that is, investments will have value which more or less can be transformed into cash.

Responsibilities:

• Calculate value at a given date. Value will be probably the most important quantity in the system. At the end of the day, everything is about value and how to add it. An investment object will be responsible to provide an accurate estimation of its own value.
• Maintain positions in individual instruments and/or portfolios. This will probably lead to the composite design pattern. Investments can be made in a particular instrument or a portfolio of investments, that is, portfolios will be composed of investments. In the end, this will also define the portfolio/position structure in a tree-like form.
• Maintain cash position. Necessary for implementing investment strategies.
• Estimate transaction costs. Will probably refer to a new class of “brokers/dealers”, each with its own transaction cost structure. For the time being, that class will probably be a null cost structure.

Collaborations:

• Instruments. Values are calculated as the position quantity times the instrument’s price or the portfolio’s value. In the case of leaves (portfolios), the calculation will be driven by instrument prices. Instruments will probably be implemented using a flyweight pattern to reduce the amount of simulations required to produce reliable theoretical prices.

Instrument

Instruments are responsible to provide a price, historical or produced by a model. Historical prices will be loaded from a database. Models will be associated with instruments on a one-to-one relationship (using the bridge pattern). This will provide the flexibility to develop the portfolio/instrument management system independently from the pricing models.

As well, it would be beneficial to refer one single instrument to all the positions in the same instrument. This seems a likely place for the flyweight pattern. Flyweight instruments would be put in place, where are links to the actual instruments would be kept by the positions. The benefits of this are when simulations are run and try to enforce a single representation of each object in reality to an object in the model.

Responsibilities:

• Provide its own price at a given date.

• Maintain a link to a pricing model.

Collaborations:

• Flyweight pattern will ensure that only one instrument object is instantiated and referenced in the different positions held among portfolios. This will require that the investment class provide an encapsulation for the external state of each flyweight. As far as I have thought, only position data could be considered as external encapsulation.

PricingModel

PricingModels will be instantiated on a one-to-one relationship with instruments (bridge pattern). They will be the providers of theoretical prices which ultimately will be functions of scenarios.

Responsibilities:

• Provide theoretical price as a function of risk factors.
• Provide interface for scenarios. Each scenario will be a set of risk factors. The interface required will tell some sort of scenario generator what risk factors the model needs, this way each simulation can be constructed ad-hoc.

Collaborations:

• Instruments (Bridge pattern). The primary reason models exist is to represent the actual price which can fetch a transaction in an instrument in the market. The reason why this class exists is to encapsulate the behaviour of providing a theoretical price. In this manner the library of pricing models (our understanding of the world) can be independent of the actual instrument (the world).

Curves: risk factors and scenarios

The Curves class will implement a Composite Design Pattern similarly to the positions/portfolio pattern. A question to decide is how to represent ‘actual’ curves: as an additional composite of individual nodes (leaves) or let the implementation handle everything?

The curves class will have to subclasses: risk factors and scenarios. Risk factors are the theoretical constructs in which our instruments’ pricing models depend. It is between the selection of the pricing models and the representation of risk factors that the quality of our theoretical pricing depends. A risk factor is responsible of providing its state. In order to provide its state, the risk factor must calibrate itself with a set of instruments.

Responsibilities:

• Provide its state. Historical and calibrated states will be required.
• Calibrate itself to a set of instruments.

Analysis: statistical, risk, technical, …

Analyses will be operations performed on portfolios. They will primarily entail a large set of generated scenarios under which the value of investments will be calculated and reported. Scenarios might be historical or theoretical.

I need more time on this.

Others

Other classes will be needed for interfacing with data bases, data mapping, GUI and report generation.

1. Decorator Pattern
   • Another Example
2. Proxy Pattern
3. Bridge Pattern
4. Composite Pattern
5. Flyweight Pattern
6. Adapter Pattern
   • Two Way Adapter Pattern
   • Pluggable Adapter Pattern
7. Facade Pattern
8. Prototype Pattern
9. Factory Method Pattern
10. Singleton Pattern
    • Generic Singleton Pattern
11. Abstract Factory Pattern
12. Builder Pattern
13. Strategy Pattern
14. State Pattern
15. Template Method Pattern
16. Chain Of Responsibility Pattern
17. Command Pattern
18. Iterator Pattern
19. Mediator Pattern
20. Observer Pattern
21. Visitor Pattern
22. Interpreter Pattern
23. Memento Pattern

Last week was my first presentation while playing the Solution Architect Role in ArabiaGIS, so I tried to start with an introduction to design patterns, and my first subject was the Model-View-ViewModel design pattern. in the presentation I tried to introduce the design pattern concept, showing its importance and the goals off applying it.

The presentation will focus on the history and the importance of MVVM and then go into the detailed of this important design pattern for architecting a WPF application.

 To see the presentation: http://www.slideshare.net/Jaffel/introduction-to-design-pattern-mvvm

Pattern-Oriented development is paramount in IT.  Patterns are used for designing software [POSA], integrating applications [EIP] or building enterprise systems [PEAA].  They make us feel comfortable that are our solution in the end will be extensible, reusable and hopefully along the way we managed avoiding some age-old pitfalls.

One thing enterprise software architecture teaches us is to rely on layers.  There are various patterns and styles of layers but more than likely if you are missing layers you are missing the mark with your framework.  Inside the context of integration landscapes and even application development, the introduction of “services” has greatly improved our ability to leverage layers well – make them more understandable, reusable and frankly standard.

Services & Layers

Services can mean lots of things, from a simple exposed interface to a data object, to an managed end-to-end business process, to an  interactive SOAP web service or EJB.  But at the end of the day, the term service has become common with the “stuff” or components we should be interacting within our layers.

If it’s a data layer, then provide me data-access CRUD like services.  If it’s a domain layer, provide me with business process logic.  If it’s an application layer, provide me with interface adaptors.  It it’s a presentation layer, provide me with representational views. And the list goes on and on, but we all agree we should be employing our patterns with services in mind in both development and discussion.

Does this therefore mean all architecture lends itself to Service-Oriented Architecture?  Well – no.  Service abstraction is something service-oriented architecture leverages but in practice an SOA is far more.  Furthermore, I contend that due to this lack of understanding, there is a very high risk of creating a “Service Architecture” (SA) and missing the boat all together on the sought after “Service-Oriented Architecture” (SOA).

Service Architecture

The SA is something we rarely talk about and only whispers can be heard of it in JAD meetings, or final production audits.  As a definition, I will give it this:  An Integration Landscape focusing on providing interoperability primarily through exposing and managing services across the enterprise.   In short, take your spaghetti code and stovepipe applications – re-architect them using services and layers (ignoring the true patterns from whence they came) – and you are left with an expensive replica of what you had: a point-to-point mess only this time with fancy service names attached to all those tightly-coupled interfaces.  And just because you decided to run all this on top of the latest “ESB” you hope to god the resultant SOA guarantees all the power it touts.  For this reason, I have grown to hate the term “integration point”.  As if all I need to do is define some necessary communication /action and provide some code to interoperate and “voila”, a true “service” comes out and now we are on our way to an SOA.  Sorry to say nope – designing integration landscapes by focusing on integration points, will usually get you quickly to a place where “web” and “point” are frowned upon.  (Referring the web chaos of point-to-point architectures).  Unless of course you were going for P2P, but since this BLOG is about SOA, I would assume you are not – and thus frowning is applicable.

Service-Oriented Architecture

SOA has evolved to mean so much, maybe too much, but at the least it is associated with a series of highly desired characteristics of enterprise application architecture.  Benefits like agility, governability, real-time, guaranteed, extensible and intelligent add to our ROI while benefits like reusability, maintainability, operational efficiency, automation, auditability reduce our TCO.  So how do we ensure we get all this?  Is it even possible?  Or is SOA another ivory tower pipe dream big software vendors and consultants are helping us peddle?

Check out some of my previous postings for definitions of an SOA – but in short, I would have preferred the “S” stood for Standard.  As in the tried and true standards that have really stood the test of time and now we finally are smart enough to realize it and start repeating it rather than conjuring up something new for our own ego sake.  However, for this posting I will offer this up for defining an SOA: An Integration Landscape that provides both interoperability and infrastructure through a strategic enterprise solution embodying connectivity, consolidation, composition and completeness.  Before I get hammered by the SOA for dummies people who say where is mention of the business people, this is meant to constrain SOA as an integration landscape not a project methodology.  I am not trying to redefine IT departments and IT business as we know it, just pointing out that when I look at what was actually implemented, how can I tell if it was more of an “SA” or “SOA”.  Besides, I added words like “enterprise” and consolidation to include the “business” (yes the stakeholders and business owners are important) – you cannot achieve consolidation or completeness without the business. See my blog on SOA Maturity.

The big deal here is the combination of technology, infrastructure (IT resources and Business resources where resources are people, processes and tangible assets) and standardization in a way that shows evolution and maturity of thought on both sides.  ESBs, web services, integration points, BPM or even technology patterns can not achieve this alone.  For an SOA to begin to produce all the benefits it so badly wants to, it needs some old school experience to pave the way.  Don’t throw out all your old PM methodologies or Architectural gurus in favor for new age hype.  Slow down, question why, document decisions points, make sure you are actually modeling your business not technology or a deadline, and for goodness sake, make sure the solution everyone is going for actually makes sense.