How to deal with overlapping domains?

Question

I'm a Java developer and I'm try to separate my code to packages (modules, services, whatever the chosen unit of functionality is). Let's say I'm creating a system that tracks employees and the company laptops they are using (this is not a real example, I'm working in a bank).

I have an entity in my model called Employee. Each Employee has his properties, there is a service providing Employee from a persistence layer, there is a REST controller, some business logic code a separated testing code. Now we need to add another entity into our system, a Laptop that Employee uses. Laptop can exist on it's own, it has it's own DB table, own controller, own business logic for CRUD operations, own test code.

Where in the project should I put logic that works with both of these concepts. JPA entities in Java can have bidirectional dependencies, I may have some logic that if an employee is deleted, then the laptop will be put into a pool of available laptops etc..

In real life I have over 100 more or less interconnected DB tables, there are many relations in the model and I'm trying to separate that and set some guidelines for our team.

Answer 1

Specific to the Problem

An employee knows his laptop, but a laptop does not know an employee. The employee uses the laptop, and it's a good idea to put employee-laptop logic in the same package with employees.

Extension 1: To Separate or not to Separate, that is a Problem.

The 100+ interrelated DBs sounds dubious. In real world, most entities exhibit a community structure. It's likely that if you draw a graph of your DB you will find some natural clusters. It is based on this idea that we group functions into classes, classes into packages, and packages into applications.

It is undeniable that there are cases where a large number of states are interconnected densely by nature, where people don't try to separate them into classes, but bind them together in a context

For example, in a WEB frontend app, some information is ubiquitous, such as a summary of the current user status; in an electronic game, more than a few systems are interested in the player's actions. In all of these cases, you'd best put the states in a managed context, otherwise you have to pass them around verbosely.

Extension 2: An Unambiguous Design Principle for Overlapping Domains?

It's definitely normal to have overlapping domain concepts, because otherwise they won't live in the same project at all. Will you worry about how to launch a rocket when you work on a pet health monitor?

It's not always easy to identify the community for a class to live in. In fact, this is a popular research problem named community discovery. There are several heuristics, but none is dominating. Designing an architecture is still a nonautomated area and sometimes no one can tell you why exactly they think it's the best solution. It's not until recently that I learned to live with uncertainty about whether I'm making the "best" choice.

In this blog, the author mentioned a key difference between junior and senior developers:

It doesn't take much skill to notice a problem.

In fact, as developers get more and more senior, they tend to ignore more and more problems, because they've gotten so used to it. That's the way it's always been done, and they've learned to live with them, so they've stopped questioning it any more.

Junior developers however, get to look at everything again with a fresh pair of eyes: they haven't learned to ignore all the quirks yet, so it feels uncomfortable to them, and they tend to question it (if they're made to feel safe enough to voice their concerns).

Extension 3: What About a Good Design? Is it Unimportant?

Of course not. However, you won't learn real experience from reasoning or discussion alone. You only learn through practice.

My advice is to focus on the business scenario you are working on. You can build a package for employee salary management, and later another for employee equipment management. Now, you extract common logic from these two packages into a lower-level package Employee. You should put the business in front of your application, not the other way around. You package structure should mimic the domain structure, and lower-level functionalities grow out.

That being said, don't be afraid to make a bad decision. Many WEB apps are built with only three main packages, Controller, Service, and Model. They are functioning well anyway!