The Emerging Domain

and why I think it's important to distinguish it from DDD's Core Domain

Emerging Domain Definition

You want to invest strategically in a single new not-well-defined domain model to prove the business hypothesis and identify high ROI initiatives or big bets.

Emerging Domains expect to prove that a High Business Differentiator exists and discover the Model Complexity and the Ubiquitous Language and Bounded Context along the way.

Some properties of an Emerging Domain

• Bounded Context and Ubiquitous Language to be discovered/defined.

• Product Market Fit to be proven.

• Business Model to be proven.

• A lot of potentials to be a business differentiator

• A lot of potential for high ROI

• Low Team knowledge of the Domain.

  • Unknown Model Complexity

  • Unable to determine the Bounded Context

  • Unable to formalize the Ubiquitous Language

Why do I need another Domain Type?

Let’s take a look at the current DDD’s {Sub}Domains:

• Core Domain: This is where you are making a strategic investment in a single, well-defined domain model, committing significant resources for carefully crafting your Ubiquitous Language in an explicit Bounded Context.

• Supporting Subdomain: This modeling situation requires custom development because an off-the-shelf solution doesn’t exist.

• Generic Subdomain: This kind of solution may be available off the shelf. You don’t want to make that kind of investment here.

As you can see, Emerging Domain is near the Core Domain definition. It expects to return high ROI and be a business differentiator, but uncertainty is the main difference.

Let’s dig deeper into the Core Domain definition you can find in Domain-Driven Design Distilled by Vaughn Vernon.

Core Domain: This is where you are making a strategic investment in a single, well-defined domain model, committing significant resources for carefully crafting your Ubiquitous Language in an explicit Bounded Context. This is very high on your organization’s list of projects because it will distinguish it from all competitors. Since your organization can’t be distinguished in everything that it does, your Core Domain demarcates where it must excel. Achieving the level of deep learning and understanding required to make such a determination requires commitment, collaboration, and experimentation. It’s where the organization needs to invest most liberally in software.

I find the definition of Core Domain to be the right one. Yet, I think that, as developers and architects, we tend to over-engineer when we suddenly say, “this is our core domain.”

Suddenly, the resources needed to develop this core domain explode, we over-analyze, we ask for three more developers, more Event Storming Sessions, and the premium of XYZ, to name some.

Yet, we are still to prove its value. We are very in the early beginning of the Domain! We cannot predict if we will rock it or if it’s a failed big-bet initiative.

I need a middle ground. A domain that we want to invest in, but not over-commit until we have proven its value, like proving Product-Market Fit.

In summary, relaxing the requirements of the Core Domain. I see several benefits here:

• The business will have the possibility to invest more resources in discovering several Emerging Domains.

• By being able to invest in several Emerging Domains, the possibility that some of them will become Core Domain is higher.

• Reduce the cost of Experimenting in areas where we envision high business differentiation and ROI.

• Reduce the pressure of having a clear understanding up-front of the Domain, its Ubiquitous Language, and Bounded Context. You learn about it in short iterations. You acknowledge that the UL and BC will rapidly change and make that an expectation until transitioning to Core Domain becomes stable.

• Architects and other decision-makers will not feel the urge to have well-defined Bounded Contexts up-front, making the Model and Services more rigid than they need to be because they have chosen the BC without enough knowledge. Emerging Domain gives that flexibility of committing to experiment so later you can make the right boundary decisions.

Emerging Domains evolve to _

The fate of an Emerging Domain is either to become a Core Domain or die. Yet, some will stay in a live-dead state, which, IMHO, it’s the most annoying outcome. The worst is to become a BBoM.

Emerging → Core

Hard to tell since it depends on your Context. I will share some signals I look for:

• There’s Money Flow

• The company starts investing in the team by hiring new people, for example

• There’s increasing usage of the features

• There’s an increasing user base

• Stakeholders or Business Owners started to give attention to developing more features there.

• Marketing starts growth campaigns for the solution

• You start receiving Customer Complains because that doesn’t work

• Outages due to increasing traffic

• The team will start complaining that

  • The Code doesn’t represent the Ubiquitous Language. 👈 This is a strong indicator that you started to be Core Domain

  • The Code doesn’t correctly model the domain understanding

• Someone said so 😂

It’s not an exact science when this happens, but you can sense it.

The time between you start an Emerging Domain, and it becomes a Core Domain varies from company to company. I don’t have a maximum or a minimum.

When evolving to Core Domain, you will:

• Have a well-defined Ubiquitous Language and Bounded Context.

• Good understanding of the Business Model

• Processes are in place, where some might be manual and some automatic.

  • You know, the ones that are more used and need more automation and those that don’t.

  • You know the limits of the processes and how to overcome them.

A Core Domain is always the result of evolving from Emerging?

I don’t think so. I think that you still have several scenarios where a domain is directly a Core Domain without the need to be first an Emerging Domain. The same way that you choose a part of your business to be Supportive or Generic Subdomains.

Ultimately, it’s a decision about how you see the business landscape and strategically choose how to split the Domain.

Emerging → Big Ball of Mud

This happens when you miss that the Emerging Domain needs to evolve into Core Domain. Sadly, this is more the norm rather than the exception.

You start to succeed in this new Emerging Domain, and you continue with the same practices and methodologies.

No-code, excel files, or manual processes that led you to succeed, are the same that will prevent you from having a huge competitive advantage against your competition.

The business starts to invest more in this Domain, it needs to evolve, but the practices and investments don’t. The considerable pressure from the business to start evolving that we did before slowed us down, creating coupled, non-well-designed solutions and not dedicating the necessary effort to the Ubiquitous Language.

Suddenly, we created a BBoM due to missing that our Emerging Domain evolved into Core Domain. 😔

Emerging → RIP

Thanks to considering this part of the business as an Emerging Domain, removing the solution is cheaper and more convenient than when you make that part of an existing Core Domain, and the coupling is higher.

One of the excellent properties of an Emerging Domain is that you can remove it from the product when the business needs have been proven wrong.

Is this a new Emerging Domain or only an extension of our Core Domain?

I saw two well-distinguished patterns. Either you:

• Extend the current Core Domain Boundary by adding this new concept

• You start a new Emerging Domain that’s usually, but not always, connected to the Core Domain.

When Extend and when to Emerge?

The business’s needs should drive this decision. It’s a bet. I usually do some questions that help me understand in which direction should we go:

• Is it a new business capability or part of an existing one?

• Which is the user journey? Is extending an existing one or a new one?

• Is the Ubiquitous Language well understood?

• Are we confident of the ROI?

• Did we validate the Business Hypothesis?

The more you can understand the business, the more educated decisions you will make.

Is it a new microservice?

Not necessary. It depends on your architecture and engineering strategy.

I saw Emerging Domains as new microservices when the tooling to create and integrate new microservice is effortless (not maintenance less 😅), like up and running in production in less than an hour.

I also saw Emerging Domains and segregated Modules within a Monolithic Service. Sometimes is as simple as:

• `https://mycoolproduct.dev/product/**`: Core Domain

• `https://mycoolproduct.dev/tasks/**`: Emerging Domain

And then, based on the URL, you can have that good separation of Domains.

The cost of evolution and experimentation should drive the decision.

Do not confuse an Emerging Domain with a Supporting Subdomain! 🚨

You might fall into the trap of identifying that something doesn’t belong to a Core Domain but then missing that it might be a Supporting Subdomain instead. Where you should consider Buy vs. Build.

I always seek already Buy/Off-the-Shelf Solutions before making a decision.

Consider doing a Context-Mapping to identify those boundaries and how they are connected.

Emerging Domains and Prototypes

Do I consider a Prototype to replace the Emerging Domain? No.

I think Prototypes can help you grasp a good understanding, use them for user interviews, and gather good product insights.

How I see Emerging Domains are what comes next. After you have a hypothesis that might be worth investing in a product or business domain, then you start the Emerging Domain.

Emerging Domains are MVPs

Emerging Domains focus on validating a business hypothesis. What does work well to validate that business hypothesis without wasting a lot of resources?

An MVP.

IMHO, it just makes sense to capture this part of the exploration, experimentation, and iteration until you define a business hypothesis that nowadays is well established in the industry within Domain-Driven Design.

Are there other ways to make an Emerging Domain that aren’t strict MVP? Yes. But you got the idea 😄

Emerging Domains and Wardley Mapping

Looking at the properties of the Generis evolution stage, it fits into the Emerging Domain properties.

I was inspired by Wardley Mapping + DDD + TT Course from Susanne Kaiser and how she mapped those concepts of DDD and Wardley Mapping.

Yet, I was missing some Subdomain of DDD when talking about big bets and initiatives on something you still don’t know if it’s core, and it brought me a lot of thinking on how to map it.

Now, you and I can map them as Emerging Domains 😄

Do we need the Emerging Domain?

DDD is about Tackling Complexity in the Heart of Software. If an Emerging Domain is an MVP, it shouldn’t be too complex, right? Why, then, the Emerging Domain?

We must embrace DDD as part of the Domain Type journey, not only because of the complexity.

I do think that adopting DDD in the right way in an Emerging Domain can result in more manageable complexity when transitioning to Core Domain. In short, don’t let the Emerging Domain become a BBoM.

I know DDD can help a lot in areas we are yet to prove worth the investment Core Domain needs. Acknowledging that there’s an expectation to evolve from Emerging to Core makes this part of the Domain Type Live Cycle.

We normalized that a Core domain eventually becomes a Supportive or a Generic. Now, we need to normalize MVPs as Emerging Domains becoming Core Domains.

Moreover, I think adopting this approach and nomenclature can reduce the inertia of introducing DDD in the project at the right time.

“If we succeeded without DDD, why do we need it now?” - Decision Maker when wondering why we need DDD after succeding with an MVP.

Making DDD part of the whole Product Evolution Journey will help you adapt to the different product/business needs and will be something natural for the whole team.

Is this new?

No.

I think we have been applying this within the DDD community. I’m not inventing anything here. I missed a word for something we have been doing implicitly. 😄

Summary

• Emerging Domains have been part of our day-to-day for a long time.

• We miss properly treating them to prevent them from becoming BBoM

• By not identifying if something belongs to a Core Domain or an Emerging Domain, we start coupling the Core Domain to new models.

  • This also influences a well-defined Core Domain to become a BBoM

  • or slows the necessary experimentation phase we need in the Emerging Domain because we mistakenly treat it as a proven business need. Losing competitive advantage and making experiments more expensive than they should be.

• Emerging Domains represents the reality when the Domain Model and Ubiquitous Language are still not known enough by the team.

  • Core Domains are continuously evolving the Ubiquitous Language as well. The critical difference is that rapid Ubiquitous Language evolution is expected in the Early Begging of an Emerging Domain. In Core Domain, you have a more stable Ubiquitous Language.

Meme for you

Big thank you to all people that provided that meaningful feedback 🧡

CC BY-SA 4.0

This post is provide as Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) by the original author, Aleix Morgadas.