IntoFactories.NET

Last time we spent some time separating the domain layer from the rest of the application using a Layered Architecture. This time we will take our first steps into the design of the most important layer: the domain layer.

The goal of the domain layer is to capture all the business logic that applies to the domain that we are writing software for, hence its important that the source code for the domain layer reflects the true domain as much as possible.  Why? Well, this way you can use the source code as a means of communication with all members of the team and with the eventual consumers of the application, in fact all concepts that will be discussed in the upcoming chapters should be part of this common language, called the ‘Ubiquitous Language’.

Code an sich does not lend itself very well for communication does it? It contains a lot of chatter, like point comma’s, curly braces etc… just for the sake of getting it compiled. A better way to communicate the code is using a model, a graphical domain specific representation of the code. This is where DSL’s or Domain Specific Languages come in, they can provide a graphical representation of code which is specifically tailored for the problem domain and as such DSL’s can bridge the gap between the code and the Ubiquitous Language. An excellent example of a DSL can be found in the Visual Studio Class designer, which is nothing more than a nice DSL on top of code that represents classes.

A DSL is a great way to present the concepts in a given problem domain, like the concept of a class or a workflow, as long as the concept you want to show is expressable as a graphic. But many enterprise models are just to difficult or to wieldy to capture at one glance, which is one of the biggest problems for a graphical DSL.

Next time we will look into the options we have to separate the different parts of a large model into distinct parts.