TL;DR

• Use Domain-Driven Design (DDD) strategic patterns to categorize your software landscape into core, supporting, or generic subdomains.
• Make or heavily customize core subdomains to maintain a competitive or operational edge; buy commodity solutions for generic subdomains to save resources.
• Event Storming and analyzing coherent use cases help you discover the right boundaries and drive your make-or-buy decisions.

A Note on DDD References

There are many valuable books about Domain-Driven Design, but the one I like most — and whose mental models and definitions I rely on — is Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy by Vlad Khononov. It provides clear explanations of both strategic and tactical DDD techniques, making them straightforward to apply in our consulting engagements.

DDD Beyond Greenfield

Many public-sector organizations start with tools like Microsoft Excel or Access because they’re fast and cost-effective early on. This is a smart move for simple workflows and tight budgets. Over time, however, these ad hoc solutions can become critical bottlenecks, hard to maintain or integrate. DDD’s strategic design addresses this challenge by mapping out exactly what needs a custom build versus off-the-shelf solutions or minimal adjustments to existing spreadsheets.

Splitting the Landscape into Subdomains

A core principle of DDD is recognizing that not every business capability is created equal. In our practice, we group processes into subdomains:

• Core Subdomains
  Uniquely valuable or specialized business capabilities that set you apart. These tend to change frequently under new requirements or policies, making generic solutions insufficient.
• Supporting Subdomains
  Necessary but not crucial for differentiation. If your Access or Excel system works and is stable, you might leave it be or replace it with a lighter-weight custom solution.
• Generic Subdomains
  Well-understood commodities (e.g., payroll, scheduling) already solved by off-the-shelf products. Procurement is typically cheaper and faster than building these from scratch.

We weigh complexity, volatility, and business impact when deciding subdomain types. A domain that changes often or impacts many stakeholders likely deserves a more sustainable or extensible system.

Quick, Inclusive Discovery: Departments and Event Storming

We begin by interviewing departments and organizational units to see how they operate. We follow up with Event Storming — a collaborative workshop capturing major events like “Application filed,” “Citizen record updated,” “Payment processed.” This fast, high-level approach yields:

1. Ubiquitous Language
   A shared set of domain terms for all stakeholders.
2. Subdomain View
   Initial groupings that show where each part of the organization’s work might fit.
3. Process Diagrams
   Simple flows revealing which areas have complex rules and thus might need custom solutions.

How Do We Find Subdomains?

Subdomains as Coherent Use Cases
Subdomains typically revolve around sets of use cases handled by the same actor(s) and working with closely related data. If a workflow’s participants and data remain consistent across multiple processes, those processes tend to form a cohesive subdomain.

Example: Public Sector Agency — Internal HR vs. Citizen-Facing Services

Recently, we helped an organization from the public sector overseeing their entire software landscape and workflows which included HR processes for its workforce, as well as specialized labor services for citizens. Our subdomain analysis pinpointed two very different solutions:

• Citizen Labor Services
  A Core Subdomain requiring tailored workflows and frequent policy changes. Generic solutions couldn’t handle the evolving rules.
• Internal HR
  A Generic Subdomain, since well-established market solutions easily covered common HR tasks.

When to Make and When to Buy

Once each subdomain is identified as core, supporting, or generic, the course of action is clear:

1. Core Subdomains
   Make or heavily customize the software so you can handle frequent updates and maintain your advantage.
2. Supporting Subdomains
   Maybe keep existing spreadsheets if they pose no risk, or commission a simpler custom solution if needed.
3. Generic Subdomains
   Buy standard market products. Don’t reinvent the wheel or invest resources in problems someone else has already solved effectively.

Buy: Potential Challenges and Stakeholder Management

While using standard, off-the-shelf solutions for generic subdomains is often the most efficient choice, some challenges may arise during implementation. One common issue is feature requests that exceed the capabilities of these standard tools. Stakeholders may have specific requirements that are not covered by the off-the-shelf products.

In such cases, effective stakeholder management is crucial. It’s important to clearly communicate the limitations and possibilities of the purchased solutions and to manage expectations. Often, individual requirements can be met through adjustments or workarounds without needing complete in-house development.

However, it’s worth noting that even when such challenges arise, there’s usually little reason to develop generic subdomains entirely in-house. The advantages of saving time and resources by using standard solutions typically outweigh the drawbacks. It’s essential, however, to carefully examine emerging feature requests and, through transparent dialogue with stakeholders, decide which adjustments are reasonable and necessary.

Conclusion

By focusing on DDD’s strategic patterns, you can systematically decide where to invest in custom development and where to leverage proven off-the-shelf solutions. This approach lets you preserve the agility and specialized workflows your organization needs in its core subdomains, while saving time and money on generic or lower-impact domains. Whether you’re dealing with multiple Access databases or a sprawling application landscape, start by identifying the subdomains and categorizing them by strategic value and complexity. Once you see the big picture, the make-or-buy choice becomes easier — and far more effective.

Want to Discuss or Need Consulting?

If you have questions about these ideas or could use consulting support to apply them in your organization, please don’t hesitate to reach out. I’m always happy to connect, explore the details of your specific challenges, and discuss how Domain-Driven Design practices can help you achieve sustainable, strategically aligned architectures.