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.
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.
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.
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.
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
Fig. 4: Domain chart
As presented in the chart [Fig. 4], we can distinguish between:
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.