A domain driven design example: building a group website so any business can stand alone

Domain driven design means organising software around the parts of the business rather than around technical layers. A practical domain driven design example is a holding group website where each subsidiary lives in its own sealed module, with its own logic, content and styles. Any one business can then be sold or relaunched on its own without a rebuild.

What does domain driven design mean for a group with several businesses?

For a group with several businesses, domain driven design means the website's code is split along the same lines as the company: one self-contained module per business, not one shared block. Developers call each module a bounded context, which simply means a walled-off area of the software where one business's rules and content apply and nobody else's.

Most group websites are built by page type instead. All the headers live in one place, all the careers pages in another, and one big stylesheet colours everything. That works while the group keeps its shape. The problem shows up when one company needs to leave and its pages and styling are threaded through everything.

A domain driven design architecture does not mean a pile of separate systems. For most groups the right size is a modular monolith architecture: one codebase and one hosting bill, with firm internal walls between the businesses. It pairs well with a headless setup that keeps the content system separate from the website, since the content splits along the same lines.

Why does website structure matter when you sell or spin off a business?

When a business unit is sold or spun off, its website and systems have to go with it, and a site built as one shared block turns that into a rebuild instead of a move. BusinessTech reported in November 2024 that the biggest JSE listings that year were unbundlings: WeBuyCars from Transaction Capital, Rainbow Chicken from RCL Foods and Boxer from Pick n Pay. The JSE's Sam Mokorosi put it down to weak economic growth, expected around 1% that year, which pushed many companies to unbundle to get value to shareholders.

A family holding company selling its logistics arm faces the same problem on a smaller scale, with a deal timeline nobody wants the website to hold up.

We built a group website on this principle for a maritime and fishing holding group with six subsidiaries and seven brands under one roof. It took 11.5 weeks, with us also acting as the group's embedded CTO. The front end is Astro 5 with Tailwind, fed by a self-hosted Strapi 5 CMS on Google Cloud. In the repository, every subsidiary has its own folder, and each folder is a sealed capsule with that company's own logic, content and styles:

src/modules/<subsidiary-one>/
src/modules/<subsidiary-two>/
src/modules/<subsidiary-six>/

We designed it so that if the group decides to launch one of those businesses as a fully independent platform, its capsule can be extracted into a standalone repository in under four hours.

The part most guides skip is that the walls only hold if someone defends them. Every time one company's page borrows code from another company's folder, the wall cracks a little, and after a year the capsules are capsules in name only. Defending those boundaries is a large part of what a fractional CTO actually owns on a build like this.

Should your business use domain driven design?

Use domain driven design when your business is made of parts that could one day live apart, and skip it when you run one business under one brand. Holding groups, companies planning acquisitions and owners who might sell a division are the clear cases. Franchise networks sit close to this too, and the same thinking applies to franchise website software built for many locations. A single-brand SME or a first MVP gets little from it.

If you are briefing a developer on a group site, ask what they would have to untangle if you sold one of these companies next year. Then ask which parts are shared across all the companies, and who decides when something new becomes shared. A vague answer to either means the boundaries do not exist yet. The shared look is its own decision, and a design system that lets several brands share one set of components keeps the group consistent without welding the businesses together. That thinking belongs in any custom software development project where the business is likely to change shape.

If your company is one business under one brand, build simply and do not pay for walls you will never use. If it is a group, or you can picture the day one part gets sold or relaunched, organise the software by business from the start. Putting those walls into a finished site is a far bigger job than drawing them before the first line of code.

Questions about domain driven design

Is domain driven design worth it?

Yes, when your business has distinct parts that change or could separate, such as subsidiaries, brands or franchise regions. It costs more thinking up front and some discipline after launch. For a single business with one brand, it is usually overkill, and a well organised codebase does the job for less.

Is domain driven design still relevant?

Yes. The problem it solves has not gone away: software organised around the business is easier to change when the business changes. If anything it matters more for groups that buy and sell units, because the cost of a tangled codebase shows up exactly when a deal is on the table and time is short.

What is a domain driven design project structure?

A domain driven design project structure groups code by business area instead of by technical layer. On a group website we built, each of six subsidiaries had its own folder under /src/modules/, holding that company's logic, content and styles. A shared Tailwind design system supplies the common components, while each company keeps its own brand colours and identity.

What are the alternatives to domain driven design?

The common alternative is organising code by technical layer, with all pages in one place and all styles in another. It is quicker to start and fine for one business. Other options are separate codebases per company, which duplicates work, or microservices, which split a system into independently deployed services and add running costs most SMEs do not need.

Does domain driven design mean microservices?

No. Domain driven design is about where you draw the boundaries in your software, not how many servers you run. A modular monolith keeps one codebase with firm walls between business areas. The group website we built works this way: six subsidiary modules inside one Astro codebase, fed by a single self-hosted Strapi CMS.

Why are South African companies unbundling business units, and what does that mean for their systems?

Weak growth, mostly. BusinessTech reported in late 2024 that, with economic growth expected around 1% that year, many companies unbundled to get value to shareholders; WeBuyCars, Rainbow Chicken and Boxer were the big listings. Each separated business needs its own systems, and software with clear internal boundaries is far easier to split than software where everything is shared.