Domain-Driven Design (DDD) is a powerful approach to software development that emphasizes the importance of the domain and its logic. However, propagating it to the database entity design is not a usual habit and can be quite tricky. This article explores the principles and implementation strategies of DDD with Java Persistence API (JPA), offering practical insights for developers.
Some Codebase Context
In the following chapters, we consider the project as monolithic, but split into several modules (Maven ones), each one dealing with a sub-domain of the backend. No dependency exists between them, at least no entity-related ones, to respect the Single Responsibility Principle (SRP) that goes along with DDD. Thus, the idea is to make the database entities of each sub-domain cohabitate with other sub-domain entities while sharing a single database schema. As a consequence, the entities will kind of overlap, but without being tangled altogether. Hence, to be aligned with DDD and maintain proper domain boundaries and responsibilities, the key idea is to look at them as being some facets of the database tables.
The Core Principles
The very main principle is to apply Single Responsibility Principle (SRP) for writing data: only one sub-domain must be in charge of writing into a column of the database. Other sub-domains will either not consider the column or only read it.
The second principle is to allow read overlap: several domains may access the same column in read-only mode.