Micro-Domain Architecture

In this article, I will lay down some ideas on a possible way to orchestrate the creation of complex Products and make them easy(er) to understand and work with.

Throughout almost 20 years of working with web development, from the first Under Construction GIFs to Big Data apps, I've identified some ubiquitous pain points in my beloved industry:

• domain knowledge: how does Invoicing work? How does Shipping work? Supply Chain Management... what the heck is it?
• cross-domain interoperability: create a new Customer WHILE creating a new Invoice. Who builds what? Is it the Customer's team? Or Invoicing team?
• organization setup: business units, divisions, groups, teams – hiring and retaining Engineers, Architects, IT, DevOps, SREs, Designers, Customer Support, Scrum Masters, Product Owners, Product Managers, Project Managers, Engineering Managers, Staff Managers, Agile Coaches... It's a f**ing army to feed.
• communication: every time Mario says something to Luigi, a princess gets into big trouble. People misunderstand people, servers lose packages, and data formats keep changing.

My reference is the Enterprise Product, where you have to think in 10-15 years lifecycle chunks, and you may have to deal with tens of teams that concurrently build one giga-monster Product the size of Amazon or similar beasts.

Nevertheless, you can use Micro-Domain Architecture to structure and simplify the creation of any kind of product, even if it may be a tiny bit overshooting the needs of a simple proof of concept.

But I can't take full credit for the ideas in this article.
As it turns out, Mother Nature beat me to it.

Let's consider the Cell, one of the basic structures of all organic Life:

The plasma membrane (of a Cell) is a composite material, which forms a semi-permeable barrier and an interface for communication between the intracellular and extracellular environments. (source)

Yes, I love biology. And you should love it too, for so many complicated Computer Science – and people – problems find their solutions in RealLife™ and biology.

Web Apps have a lot in common with Cells:

• They have one Single Responsibility: Twitter manages billions of simple messages, and so do the Neurons in your brain
• They have a complex internal structure: Web Apps have micro-services  that perform specific jobs that contribute to the App's mission, and Cells have organelles that do the same
• They communicate with the environment: As Web Apps have public APIs, Cells have a Membrane that is responsible for letting specific substances in and out at particular moments using targeted receptors (aka endpoints)

This article focus on the Cell Membrane and the Customer-Facing Layer (API + UX) of a Web Application.

A Cell's membrane has a lot in common with the Customer-Facing Layer of a complex Product:

• It's a composite material: Web Apps often use more than one technology in their frontend, backend-for-frontend, backend, and data layer
• It's semi-permeable: any Web App needs an Authentication and Authorization layers to block unwanted requests and filter legit ones
• It's an interface for communication: behind any front-facing layer, we often find countless micro-services that solve specific problems. The membrane – and the APIs – connect the proper message with the appropriate operator – or micro-service – under the hood

All of these biology-to-computer-science comparisons were necessary to explain where the name "Micro-Domain Architecture" comes from:

Simple and clear,
isn't it?

Yeah, if you are a bit like me, you can't make heads or tails out of this sentence! 😬

So let me help out and identify the actual keyword:

It is almost embarrassing how this particular keyword applies seamlessly to both the world of Biology and Computer Science. Especially when you think in terms of Domain Driven Development – DDD.

Domain != URLs (for now)

When you approach an Enterprise Product and begin to apply DDD to its Single Responsibility – or Mission, as in "we sell stuff online" – you will likely identify multiple sub-functions that are well isolated and mostly independent from one another:

• Inventory
• Shopping Cart
• Checkout
• Discounts
• ...

Nowadays we turn to Micro-services as the de-facto standard for the organization of isolated responsibilities.

And Micro-services are an excellent choice, and we need them the same way a Cell needs its organelles. But aren't we forgetting something? What about the membrane?

More often than not, we end up with an arbitrary-organized backend and a messy monolithic monster of a frontend, or Customer-Facing Layer. For it could also comprise a backend-for-frontend layer.

We clearly need a better way to organize our work, teams, and Micro-services.

Welcome the
🎉 Micro-Domain Architecture 🎉

A Micro-Domain identifies a well-scoped portion of the Customer Facing Layer that targets a group of Micro-Services and provides a specific Function to the Product and its users.

A Micro-Domain comprises:

• a group of backend Micro-services
• a composable API layer
• a frontend App of some kind

[[ SCHEMA GOES HERE ]]

As it turns out, Micro-Domain Architecture is not even a new thing in Computer Science and the art of building Websites or Web Applications.

It's the name I think best represents what I believe to be the internal organization of mature organizations such as Microsoft, Google, and Facebook... have you heard of them?

I believe people at Office.com got it right

Office.com's goal (but the same works for GoogleDocs) is to provide a productivity suite online. It is a complex Product that supports many different Functions:

• manage documents
• handle your daily emails
• communicate with your colleagues

Those are specific portions of Office.com's business value that are represented by different Apps:

• Sharepoint
• Outlook
• Teams

And implemented in sub-domains, probably by different teams distributed around the globe:

• tsspa-my.sharepoint.com
• outlook.office.com
• teams.microsoft.com

But all those Apps, as different as they may be, have quite a lot in common:

• same session
• same account
• same security

And those shared Functions are just other sub-domains, really:

• login.microsoftonline.com
• myaccount.microsoft.com
• mysignins.microsoft.com

Microsoft clearly owns A LOT of different domains and sub-domains and divides its complex offering into many different pieces that are deployed – and likely built – independently from one another.

🔥 In essence, this is a Micro-Domain Architecture 🔥

And when you start paying attention to the websites and apps you use every day, you see this approach all-around at Google, Facebook, Spotify, Amazon...

I'm guessing there is a threshold of complexity beyond which you can't really do anything different.

What about Micro-Frontends?

Even before reaching such a threshold, or just within a Micro-Domain that grew big, many companies attempt something similar using IFRAMEs, the mighty technology of the Modern World.

Because you know:

IFrames are to the World Wide Web
what horses had been to the Wild Wild West

The idea is to take one single Host App and divide it up into sub-portions that can be worked out (more or less) independently.

The IFRAME offers a simple and quite isolated solution, but you can also use one of the many different available frameworks that exist for specific techs such as React or Angular.

Or just go the generic approach with Webpack Module Federation.

The way I see it, Micro-Frontends are an implementation detail of a bigger scheme of things. The same goes with Micro-Services. We can use both architectures within the scope of a Micro-Domain.

Micro-Domain Architecture operates at a higher level in which you have to think more in terms of business and User Value rather than modules and builds.

Domain Knowledge Required

Every Micro-Domain requires a specific Domain Knowledge.

It seems almost obvious. But I witness companies oversee this detail quite often, in the pursuit of parallelization of their workstreams:

• they keep moving people across Micro-Domains
• they underestimate onboarding time for new hires

In the Office.com example, working on the Word or Excel Micro-Domain means that the engineer needs specific domain knowledge in either:

• word processing and the art of authoring complex text
• spreadsheet and the art of making numbers tell a story

All the engineers need to know Java or React, but their Domain Knowledge is different. Much different.

Instead, when it comes to Micro-Services, they are likely to work within the same Micro-Domain and require more similar domain knowledge.

Think to the Word App: the spell-check service and the word-count service are technicalities to the Word Processing Domain.

How do we keep it all together?

That's a fair question. When things get big – as they often do in the Enterprise World – integrity and uniformity (not to mention security) might become a significant challenge (or should I say a burden?)

There is only one simple answer to such a tricky question:

We do what we do – and we do software – so that some Users out there can do something with it. So, it doesn't really matter how we do what we do, as long the User has a fluent and coherent experience with what we do.

You can build a monolith, a Micro-Frontend aggregation of IFRAMEs, or a collection of independent Apps neatly organized in Micro-Domains.

All works as long your Users say it does.
And they say so when they are willing to pay for your services.

But when it comes to Micro-Domains, it gets trickier than ever. Because you can build each domain with a different technology: one in React, the other in Vue, the third in Svelte. Do you get the gist?

Yes, you can even use Angular if you are so inclined 😉.

I always vouch for reducing the amount of tech and sponsoring a more profound knowledge of a few selected tools.

It's not this article's goal to give out "do this, do that" tips because Micro-Domains Architecture is just a fancy name for a high-level organization of problem/solution tuples. But if you really ask me...

I'd go for React and a shared library that exposes framework-level functions such as:

• authentication
• client-server communication
• cross-domain linking

Therefore, such a library should also take care of a few visible things:

• UI Components (maybe based on an existing Design System?)
• UI Shell (stuff like a toolbar and coherent routing)
• Provide shared functionalities in the form of panels or popups for stuff like account management, notifications, settings

But again, this is just the approach I'd take, and there is no assumption it is more or less correct than others.

Make it Accessible!

Accessibility is a ten(s)-year-old hot topic. I'm not going to bother you with font size, color contrast, and spacing. Those are just implementation details of it.

I would take this opportunity of having you still reading my ravaging reflections to address the one and only Universal Accessibility KPI of anything:

Everyone wants the best product, tool, or service. But not everyone can afford its price. Pricing is a challenging subject, for it can heavily affect the success of an enterprise and, eventually, the distribution of any product.

The cost of a software product is mainly affected by the salary of all the people working on it
– A. Manager

Therefore, wasting people's time means increasing the Product's price without an increase of the Product's value. An increased price often leads to a reduction in sales and compression of the company's revenue.

In my experience, the heaviest center of cost in the software production business is cross-team communication: keeping different teams' roadmaps aligned on the same goal is a true challenge.

Managers and Product Owners lose their minds following this specific white rabbit down a bottomless hole.

Then tech can mitigate such problems even more by adopting Open Source libraries (or creating them) for ubiquitous problems such:

• UI Components / UI Shell
• Client/Server Communication
• Session Management

Cross-Domain Interoperability

The last step in the cost-management journey, and the true unicorn of software production, is achieving Cross-Domain Interoperability.

Let's say our App has two Micro-Domains:

• Customers Management
• Invoicing

The Invoicing domain needs to consume a functionality from the User Management domain.

Most solutions share their backend services by providing cross-domain APIs but duplicate the Frontend components. And this duplication has three inevitable and dangerous side effects:

• it leads to inconsistent UX
• it increases the production and maintenance costs
• it requires heavy communication between Invoicing's Frontend Team and Customers' Backenders

Luckily for us, the IFrame technology is always there to support us 🤠.

We can develop each View of each Micro-Domain so it can be embedded into other Micro-Domains of the App. More or less the same as you can embed an Excel spreadsheet into a Word document.

Stuff like Query string params and postMessage() make our life easier.

But you can even go one step further and build a shared library of stateful components. Then, you could use those business-aware building blocks to overcome the Cross-Domain Interoperability issue easily:

import CustomerPicker from '@CustomerMgmDomain/CustomerPicker'

const NewInvoiceForm = () => {
  const [customer, setCustomer] = useState()

  return (
    <form onSubmit={...}>
      ...
      <CustomerPicker onChange={setCustomer} />
    </form>
  )
}

Let me highlight that sharing components slightly increases the coupling of different domains.

Even when you use dependency management tools such as NPM, different teams still need to clearly communicate new functionalities and possible breaking changes are released.

When your organization chooses this approach, make sure you get a few things right from the very beginning:

• use semantic versioning
• write detailed changelogs
• update your dependencies often

I suggest you use source-control-based static analysis tools to keep an eye on dependencies that fall behind the latest LTS and produce dashboards to visualize such information.

Waaait a minute! Is it only about the Frontend?

No, of course, it isn't!

The Frontend may hold a huge responsibility, for it sits at the top of the Customer-Facing Layer of our App, but it needs to be supported by a couple of infrastructural Micro-Services as well:

• Service Registry
• Schema Registry
• Proxy Service
• Session Delegation

For each item on this list, we have an extensive offering from the CNCF and public cloud providers... And those may be great choices in many cases, but we shouldn't blindly accept candies from strangers, right?

Mom won't be happy if we do

Take Apache Kafka, for instance. For most of the projects that I've been managing in my 20-years career, a (partitioned) PostgreSQL table would suffice. Of course, few big-scale products genuinely need the power and scalability that Kafka has to offer.

But please consider the Pareto's Principle!

Anyway, this topic alone would be a good spin-off for another long, long article.

Wrapping It Up

To my understanding, the need for synchronized information is blocking most workstream parallelization opportunities. And this costs a lot of money.

A Micro-Domain Architecture is an organization of people and tech that aims to keep under control the amount of information that different parties must exchange between different parties.

The goal is to manage the production and maintenance cost of a product and maximize true parallel workstreams.