Hi ,

Welcome to this week’s edition of ProgrammingPro!

In today’sExpert Insight, we bring you an excerpt from the recently published book, The Art of Micro Frontends - Second Edition, which explains how Domain-Driven Design principles can help define and organize boundaries for micro frontends to ensure modular, isolated, and efficient architecture.

News Highlights: .NET 9 launches with major performance boosts, including a 50% JSON processing gain; Java 24 targets memory savings with smaller object headers via Project Lilliput; the US urges developers to move from C and C++ for security; and GitHub Copilot chat adds prompt rewording guidance.

My top 5 picks from today’s learning resources:

But there’s more, so dive right in.

Stay Awesome!

Divya Anne Selvaraj

Editor-in-Chief

P.S.:This month'ssurveyis now live. Do take the opportunity to leave us your feedback, request a learning resource, and earn your one Packt credit for this month.

Sign Up|Advertise

Here’s an excerpt from “Chapter 4: Domain Decomposition" in the book, The Art of Micro Frontends - Second EditionbyFlorian Rappl, published in October 2024.

The idea of DDD was first popularized by Eric Evans. In his book, he describes the basic pillars that form DDD, according to his vision. While the book certainly has a lot of truth to it, the entire army of ideas was probably rarely—if ever—realized in real-world projects. Let’s try to distill the most important

ideas for our use inmicro frontends.

When we refer to DDD in the context of micro frontends, we will not include parts such as value objects or the need for a ubiquitous language. Instead, we almost exclusively take DDD as a blueprint to help us with the followingtwo things:

While DDD uses the wordmodules, which was back then an alias forpackages, we will refer to this unit as amicro frontend. The other thing that DDD introduces is a so-called bounded context. Finally, DDD defines a context map to make sense of it. But let’s back off and look at eacharea separately.

Amoduleserves as a container for a specific set of functionalities in your application. For a web application, this could relate to a full page or parts of a page. For instance, a module dealing with the order process could be responsible for showing a cart symbol on the pages of a web shop, such as the product catalog orproduct details.

As mentioned, a module in DDD is usually what we will bring to the table in the form of a micro frontend. Nevertheless, keeping to a general notation here makes sense; after all, this helps us to see that good architectures rarely have anything to do with specific implementations but actually would work in multiple variants. In micro frontends, the functionality will be mostly designedaround components.

A module is, however, a part of the full problem domain, focused on a specific area (or subdomain). The general design principles for modules are low coupling and high cohesion. As such, a micro frontend should represent a single unit to solve one problem without relying on any other microfrontend directly.

In reality, we will be tempted to rely on other micro frontends to simplify the code. The one strong advice here is to avoid doing that, as the immediate simplification will usually backfire in a more complicated and less flexible solution later. When we start looking at the different architectural patterns later inChapter 7onward, we’ll see how to decouple themicro frontends.

To help us figure out what could be part of a module, DDD introduces the theoretical concept of abounded context.

Abounded contextis used to define the boundaries of the functionality of a subdomain. This is an area where only the functionality from a certain domainmakes sense.

While this may initially seem similar to a module, it is actually quite different. Multiple modules live within the same bounded context. The bounded context is an umbrella connecting them and has nothing to do withruntime considerations.

Bounded contexts are also broader than modules as they contain both unrelated concepts and shared concepts. Naturally, this will result in some overlap and duplication between differentbounded contexts.

The following diagram illustrates the relationship of two bounded contexts within an exampleproblem domain:

Figure 4.1 – Relation of two bounded contexts in an example problem domain

How we split a bounded context into modules is up to us. In the end, however, a more critical question is,what are the bounded contexts in our problem domain?There is no blueprint here, but a nice way to visualize and think about contexts generally is in the form of acontext map.

Acontext mapis a useful tool to illustrate the involved contexts of a system, including their connections. Instead of reusing objects from other contexts, a transformation defined by the context map should be used to always createdomain-specific objects.

For our design decisions, a context map can be helpful to see where sharing occurs and how to still produce isolated micro frontends. To do this, we need to first identify these self-contained domains. This is where two principal ways come into play: strategic domain design and—as an alternative—tactical design. Let’s lookat both.

While strategic domain design helps us to extend knowledge of a problem domain and come up with useful guidelines, tactical design tries to come up with design patterns and building blocks that form a system. In other words, strategic domain design identifies the different domains and the communication between them, while tactical design is all about structuringthese domains.

In our micro frontend space, we have the choice of leaving the tactical design to the implementers of the micro frontends, giving them some guidance, or predefining a structure that needs to be followed already. We will see later on how these architectural boundaries can actuallybe decided.

In contrast, strategic domain design is helpful for decomposing a full problem domain into smaller (sub) domains. Starting with a full problem domain, we derive the individual subdomains and extract their bounded contexts. The relationship between the contexts is then captured in a context map. The following diagram shows thistheoretical process:

Figure 4.2 – The idealized process of deriving a full domain decomposition from a given problem domain, including a working context map

The Art of Micro Frontends - Second Edition was published in October 2024. Packt library subscribers can continue reading the entire book for free or you can buy the bookhere!

That’s all for today.

We have an entire range of newsletters with focused content for tech pros. Subscribe to the ones you find the most usefulhere.

If your company is interested in reaching an audience of developers, software engineers, and tech decision makers, you may want toadvertise with us.

If you have any suggestions or feedback, or would like us to find you a learning resource on a particular subject, take the surveyor just respond to this email!