Enterprise Software Architecture: How To Do It Part 2

This is part 2 in a series. For earlier and later posts in this series, please see here: Enterprise Software Architecture: How To Do It

Requirements

I'm going to start with a simple data entry system to record details about a company's clients. The requirements specify the following use cases:

• View details for a client.
• Add a new client.
• Edit an existing client.
• Mark a client as deleted.
• Add a site to the client. One client can have many sites.
• Edit a site.
• Delete a site.
• Add a contact for a client. One client can have many contacts.
• Edit a contact.
• Delete a contact.

Many people will be concerned that 'add', 'view', 'edit' and 'delete' are synonymous for 'create', 'read', 'update' and 'delete', and that this will simply be a CRUD system. Firstly, this is a simple example application and the more complex use cases will come later, but mainly this is very often (at least in my experience) what specified use cases look like. It's no good saying developers should not create CRUD systems when that is what they are being asked to do.

Choosing the Architectural Pattern

The architectural pattern I will be using will be the Domain Model pattern. This is sometimes described as something new and ground-breaking, when in fact all it is is good old fashioned Object Oriented Programming. The Domain Model pattern is not the same thing as Domain Driven Design, which is an approach to application design, rather than a specific pattern. Other patterns are available: Active Record, Transaction Script and Table Module are patterns generally recommended for simpler applications. However, I don't believe that Domain Module adds significant overhead, and often small utility applications can slowly creep into huge applications that run the enterprise, so I tend to use Domain Model as my default.

Much is often said of 'n-tier' architecture, placing UI at the top, followed by the Application Layer, The Domain/Business Logic Layer and the Data Layer. I don't find this description helpful or accurate. Instead I prefer to think in terms of The Onion Architecture.

Defining the Domain Model

First the entities must be identified. The entities are classes representing an element of the business. In this case, the entities are Client, Site and Contact. The realations and multiplicity between the entities also needs to be defined.

The properties of each entity should be defined, as should the behaviours. In this simple example, the behaiours will generally reflect the use cases, along with a Validate method on each class which will be used to return a list of validation errors.

This is the model we end up with:

In reality, there would probably be a more complex relationship between Site and Contact, which I have decided to omit for this simple example.