So far, we have been thinking about the problem in terms of a Model-View-Controller (MVC), web application. This brings along a certain set of assumptions that might not hold true in the case of our business domain. It is true that creating a web interface to manage input and output often does handle the presentation of an application today, but this does not mean that this part also holds the primary set of logic. In the case of our dungeon manager, it might only be one way to access and input data. An information system structured in this way has models holding the logic along with the data. These models are backed by a database, which is responsible for persistence, and is also used to implement some logic via constraints on the data. This means that our domain is pressed in the shape of the, most likely relational, database model.

All this locks us into a certain set of technologies: a webserver for hosting our application, a database for persistence, and a web layer for access and input. All these elements become the integral parts of our application and make change hard. Also, the model layer has no real abstraction besides being composed of a bunch of models. When we want to represent more complex interactions, this might not be enough. To be clear, there is no real issue with this as long as the developed application primarily consists of the interaction between systems, when however, the value proposition is mainly the business logic to be represented between parts of the system, this design starts to be not enough anymore.

In the case of business applications, a lot of problems and their respective solutions are often not explicit. This is true for many areas and an example most developers might be familiar with is setting up a webserver. When asking a developer or administrator what he has to do to achieve this, it is described in only a few steps along the lines of: set up the operating system, install Apache, configure the site, and then start. For another developer of a system administrator, this might be enough to know what to do, but this is hardly reproducible for somebody from the outside or, even worse, for a computer.

Making all the steps explicit is essential to get a grasp of what the core business domain really consists of. In our case, we need to make sure to follow what the orc master currently does to keep his dungeon running. This can be done by either following him around, or making him walk us through his normal business process. We can't, however, rely on the business expert to explain the process to us in the necessary details. Also,we can't rely on our understanding of it to match what really needs to be done.

The main goal of this exercise, therefore, is to establish a baseline of understanding for what is going on and provide a shared language to talk about the problems, which will inadvertently arise. We are in an uncertain situation to start out with. This should not scare us, but we need to see it as the opportunity to increase our own understanding, as well as sometimes even the understanding of the currently executing person. Often business experts realize new details about their domain when questioning all the steps towards a goal, and they might even identify the possible problems.

In the case of implementing a business process, we can assume that the status quo is the least we need to replicate to replace the tools the business is currently using. So, first of all, we need to either rebuild or incorporate all the tools the business is currently using. We can later find the places where optimization makes sense and is possible when we get a firm grasp on the problem in general. We should also aim for gradual replacement of processes one by one instead of one big switch, as this minimizes the risk for the business.

When working with applications, it often is a problem to create a shared language between developers, product owners, as well as the business people in general. It is often stated that naming things is one of the hardest problems of computer science, and it is true that having a describing name makes many things easier. It is also often the case that a clearly named object is easier to extend because its scope is already defined by its name. Therefore, it is often discouraged in object-oriented design to name things with general words, such as Manager, Creator or Processor. When thinking about this problem in the context of our business domain, it becomes clear that we can, and should, reuse the established business language as often as possible. It all comes down to communication. We, as the developers, are new to the field, so the business experts introducing us will already have an established language to describe problems in the domain where we are missing them.

As we follow along the steps of our business expert, we should take the time to get accustomed to the specific language that is in use throughout. This becomes even more essential as we start writing code. We will constantly need to check in with the domain experts to take their understanding into account, so when we use the business language to encode the domain, it will be easier for us to talk to everybody around us to develop a better understanding of the domain. This is quite abstract, so let me give you an example. Consider this naming for the dungeon:

function Dungeon(cells) {
  this.freeCells = cells
}

Now consider we want to record changes in the amount of prisoners, and write the following code:

var dungeon = new Dungeon(100)
dungeon.freeCells -= 5
dungeon.freeCells += 3

Even though this is natural to a developer, it does not use any business-specific language. We need to explain the meaning of things like += to non-developers to make them understand the meaning. Consider on the other hand encoding the same logic in the following methods:

Dungeon.prototype.inPrison = function (number) {
  this.freeCells -= number
}

Dungeon.prototype.free = function (number) {
  this.freeCells += number
}

Using these methods to express the same thing, it looks vastly more domain - specific then before. We can now describe the problem in the context of the domain and the code looks as follows:

var dungeon = new Dungeon(100)
dungeon.inPrison(5)
dungeon.free(3)

It will now become quite clear, even to non-developers, what is going on and therefore we can focus on talking about if the behavior is correct rather than about the details of the code.