Domain first approach to Employee Experience system for the global retailer

This article focuses on the approach we took to design and implement Rewards and Benefits systems for the global retailer company. It covers Domain-Driven Design strategic techniques used to distill models together with adequate system boundaries.

header_RA_2_3-min

A reason behind understanding the domain

Almost all large organisations struggle with the increasing complexity of their domain. This is an inevitable side effect of the company growing, expanding its domain and evolving the way it operates. Also, from the technical perspective – adding new features, integrating more systems or changing existing ones leads to the creation of a more and more tangled web of dependencies where no single person can ever understand the software as a whole.

Complexity in software is the result of inherent domain complexity (essential) mixing with technical complexity (accidental). – S.Millet

As a result, adding new blocks to the organisation’s systems is increasingly more complicated, risky and expensive. Sometimes, it is better to pause for a moment to understand the environment around. Blind assumptions about how business works may lead to overcomplicated design to an already complex system and technology-driven design not necessary will fit the business needs.

As an example, we would like to show you the journey we took to understand and design ‘Employee Rewards and Benefits’ system for the global retailer company and explain why strategic Domain-Driven Design played a huge role in our project to deliver the service that not only ‘works’ but also fits perfectly within already existing surroundings.

Find your place

We all know that hierarchy is almost unavoidable while working in a big and multinational organisation. A well-known Conway’s Law states it clearly.

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure. – Melvin E. Conway

Our team was in a very similar situation. Fortunately, there are ways to work efficiently even in such an environment. Firstly, let’s think about what the main focus is and what requires the biggest effort.

image for article: Domain first approach to Employee Experience system for the global retailer

Fig. 1: Too wide Retail domain

Obviously, for the retailer company, everything is related to retail. Nevertheless, “everything” sounds too large. When we took a closer look at the current site of internal APIs a little better representation was discovered.

image for article: Domain first approach to Employee Experience system for the global retailer

Fig. 2: Organisation silos

Some sets of API are more customer-facing when others are more employee-facing. The Employee Experience might be a good candidate to put it in later. But, thinking about our area of interest which is Rewards and Benefits for employees it wasn’t so obvious. At the very first kick-off meeting, we heard about our first goals – Discount Cards and Savings. It didn’t take long to understand that Discount Cards not only exist for employees but also for customers. There is a relation that each employee can be also a customer and some customers might be also an employee.

image for article: Domain first approach to Employee Experience system for the global retailer

Fig. 3: Overlapping Rewards and Benefits domain

It meant that our area of interest is somewhere between the employee and customer silos. We didn’t feel quite comfortable with such overlapping vision. At that moment we started digging deeper into existing structures, business units and tried to align it with strategic Domain-Driven Design patterns like domains. Good inspiration to visualise domains are DDD Domain Charts

image for article: Domain first approach to Employee Experience system for the global retailer

Fig. 4: Domain chart

As presented in the chart [Fig. 4], we can distinguish between:

  1. Core domain – a part of the system which brings the highest value for the business
  2. Supporting domain – a necessary part which accompanies the Core domain
  3. Generic domain – a part which represents common concepts which can be implemented using SaaS or other out-of-shelf product

image for article: Domain first approach to Employee Experience system for the global retailer

Fig. 5: Domains on the chart

The above chart is a result of multiple meetings with a relevant representative from the Employee Experience, Rewards and Benefits, HR, Payroll and Customer spaces. For us, it was very important to understand where our solution will sit, thus where our problem space is. The diagram depicts the importance of each domain and where it is located in terms of complexity.

Our space supports a core business. It needs to know about Customer Discount Cards and is driven by the Employee Work cycle. The generic Payroll and HR domains influence both Employee Workcycle and Rewards and Benefits. 

From there, we can dig deeper to understand boundaries and relations. Get access to full reference architecture to learn how we did it!

GET ACCESS

Written by

Konrad Jakubiec
Konrad Jakubiec Aug 25, 2020