Frontend Integration

_{Published: 06 July 2025}

Known Uses

The Frontend Integration pattern is widely used in public APIs in both the government and energy domains. To mention a few examples:

• Energieopwek.nl frontend: A public dashboard displaying near real-time data on sustainable energy production in the Netherlands.
• Eancodeboek: A web-based search interface for looking up EAN connection identification codes for electricity and gas network connections in the Netherlands.
• CBS StatLine Energy Datasets: The Dutch Central Bureau of Statistics (CBS) offers open data APIs, such as the one detailing the supply, transformation, and consumption of energy in a balance sheet format.

These APIs expose Information Holder Resources in Public APIs for Frontend Integration or Backend Integration.

Discussion Input

It is often debated whether frontend and backend should be separate bounded contexts; however, DDD defines bounded contexts by business – not technical – boundaries. Consequently, frontend and backend typically share the same context, ubiquitous language, and domain model. You should only split them when they embody different domain models or are owned by separate teams with distinct responsibilities. As a rule of thumb, if both layers use the same precise business language, they belong to a single bounded context; otherwise, distinct contexts make sense. Separation must be driven by domain considerations, not by the fact that one part runs in React and the other in Spring Boot, Node.js, or any other technology. We believe this aligns with the Lakeside Mutual context map and its refinement into core service components, as described in the book in the Architecture Overview of the Lakeside Mutual case study (p. 35).