Static context

From cdd
Jump to: navigation, search

Static context is something that is known at the time the code is written (compile time).

If we use person as an example, it can perform various tasks in different contexts, e.g.:

  • show itself in the GUI
  • answer if it's deceased
  • be a row in an export file
  • be persisted to some infrastructure

Each of these tasks represents different contexts, let's call them: "show in GUI", "core domain", "export" and "persistence". The way we allow a "person" to operate within a context is to create behaviour representations, like: Person, PersonInGui, PersonRowInFile or PersistablePerson. The following chart shows the four contexts and the corresponding behaviour representations:


CDD-static-context.png


GUI, Domain and Infrastructure are examples of layers in a layered architecture.

Layers and tier of deployment

It's often a good idea to separate different responsibilities into different logical layers in the codebase (packages/modules) to increase modularity and cohesion. Don't confuse architectural layers with tiers of deployment (well described here). Assume that you have control over all source code in your layered system. If the layers are physically separated (deployed to different physical locations) and a layer (for example the GUI) need access to another layer (for example the Domain) then the domain code should also be deployed to the GUI tier so that we don't need to duplicate our domain rules.


But is this not an example of mixing of responsibility? No, we only use the "core domain" business rules from the GUI layer, we don't duplicate the code. It's very similar to calling a service with the difference that instead of sending the state to a service and letting the service operate on it, we encapsulate the state so that we can work in a more object oriented way. For example person.export() instead of service.export(person). The latter breaks encapsulation (if not using reflection) which may lead to a situation where business rules are scattered around the system instead of gathered into one place.

The rule of thumb is that different parts of the codebase should be maintained in one place but is allowed to be deployed and used from many places. This helps to keep the code clean and DRY.


< Back          Next >