Macro Architecture

In the macro architecture perspective in figure 1, the 4-layered construction of WMS can be seen. This perspective is a kind of black-box view, which shows the logical arranged software layers, but makes no information about their internal structure. Each one of the layers has its own responsibility in order to meet the Single Responsibility Principle¹.

Figure 1: The macro architecture of the Warehouse Management System.

For a better understanding of the macro architecture, the single layers will be explained in the following beginning at the bottom.

Data Access Layer

The Data Access Layer (DAL) has the responsibility to provide the functionality required to perform CRUD operations on persistent data. In general, this is done by defining the object-relational mapping² to the database and translating between the domain model and the persistence model. The difference between domain model and persistence model is the purpose they are used for. The domain model has the focus to represent the real world domain in form of a code-based model. Thereby, it has the aspiration to meet the functional requirements of the domain. The focus of the persistence model however lies on the representation of the data model, that is driven by technical circumstances of the database.

One special thing in WMS Data Access Layer is, that for each entity a so-called DataMapper is implemented, which translates between the TDM persistence model and the WMS domain model. This is often a complex task, which is caused by the mismatch of the two models.

In order to provide its functionality to the overlying software layers, the Data Access Layer makes use of the Repository pattern³. In this context, the Data Access Layer provides an infrastructure-based technical approach to process data, which has no meaning to the domain.

Example:

When executing a storage booking in WMS, the operation's name is StoreTool(...), which has a meaning in the domain, because it matches the natural language and everybody knows what's going to be executed. When calling a simple Save(...) method, there's no meaning given in the domain, it is just clear that a particular entity is going to be saved.

Due to technical requirements and constraints on the database level, it is required in WMS to use the technical approach, which has no meaning to the domain. However, in order to provide the domain semantics for the overlying software layers, the Stock Management Layer defines management classes, which are a kind of wrapper about the repositories and bring the relevant domain meaning with themselves.

Stock Management Layer

The Stock Management Layer has the responsibility to provide stock management functionality to the domain layer, where the business workflows are represented as you can see below. This means, that the Stock Management Layer serves as a kind of abstraction for the complexity that is required to process stock movements. As described in the section before, the Stock Management Layer uses Management classes to abstract from the described complexity. This is, for example the Transaction Manager where stock movements are summarized in order to ensure the ACID properties for one booking transaction. In this context, the Transaction Manager also writes the Booking History to be able to rollback a transaction.

Domain Layer

The Domain Layer is where the business logic of the warehousing process gets being executed. In other words, this means that in the Domain Layer the flow control of the booking workflow is being managed. In this context, the so-called Booking Processors are aware of the booking process and contain the intelligence to handle all possible types of bookings. Due to the open design of the Domain Layer, we are able to place extensibility logic here in order to manipulate the booking workflow.

The Domain Layer is the place, where the booking workflow is controlled. That is, for extending the booking workflow, the Domain Layer provides the necessary functionality.

Services Layer

The Services Layer is the API for external systems to access warehousing functionality. In this context, the Services Layer provides two kinds of APIs:

• Fluent Booking Service: A booking API, which provides a fluent interface to execute bookings. The main benefit of this API type is that the developer is guided by well-defined method chaining, what ensures that the booking calls are valid.

var bookingResponse =
                FluentBookingService
                    .StoreTool("CLGR-D0200")
                    .ToWarehouse("TDM-CRIB", "TDM-CRIB")
                    .WithAmount(1)
                    .ProcessBooking();

• Booking Service: A standard booking API, which provides the three basic booking operations Storage, Booking and Withdrawal each with several method overloads.

var response =
    _bookingService.Store("CLGR-D0200", ToolTypes.Tool, "TDM-CRIB", "TDM-CRIB", 1);

The developer can decide by oneself, which API service should be used in order to execute bookings.

Footnotes

¹. See also https://en.wikipedia.org/wiki/Single_responsibility_principle. ↩

². The object-relational mapping in WMS is realized with the Entity Framework O/R-Mapper. ↩

³. See also https://msdn.microsoft.com/en-us/library/ff649690.aspx. ↩