Domain Complexity

The core domain is the part of the business that gives it competitive advantage, the reason customers choose it over competitors. It is usually complex, changes frequently and depends on deep expertise, and it cannot simply be bought, because a vendor would sell the same capability to everyone. For ShopNow it is dynamic pricing and promotions: stacking rules, margin guards and weekly campaign mechanics. The core deserves the best people, close collaboration with domain experts, rich modelling such as aggregates in a hexagonal structure, and thorough testing. The useful test is not whether it is complex, but whether doing it better than competitors makes the business win; if not, it is not core.

Generic domains are problems every business has and solves in much the same way. Typical examples are identity and access management, payments processing, notifications by email or SMS, accounting, document storage and tax calculation. They are often complex, but they are not differentiating, so mature products exist: Keycloak, Okta or Cognito for identity, Stripe, Razorpay or Adyen for payments, SES or Twilio for messaging, and ERP SaaS for accounting. The right approach is to buy, subscribe or adopt open source, configure the product rather than customise it heavily, and wrap it behind an anti-corruption layer so the vendor's model and terminology do not leak into your core domain.

The difference is whether the problem is specific to your business. A supporting domain is necessary and particular to how you operate, but customers do not choose you because of it. ShopNow's returns authorisation workflow and warehouse fulfilment rules are examples: nobody sells them off the shelf exactly as needed, yet they are not a competitive edge. A generic domain is a problem every business shares, such as identity or payments, so products already solve it well. The consequence is sourcing: supporting domains are built simply, using layered Spring Boot, low-code or an outsourcing partner, while generic domains are bought or reused. Neither deserves the investment the core receives.

Buy or reuse a mature product, and integrate it through an anti-corruption layer that keeps its model outside your domain. In practice you define a port in your own language, for example a PaymentGateway interface whose authorise method takes your OrderId and Money, and implement it with an adapter such as RazorpayPaymentGateway that translates to the vendor's API and terms like payment_intent. Domain code depends only on the port, so the vendor can be upgraded or replaced with limited change. Keep the product as close to vanilla as possible, because heavy customisation turns a generic tool into a costly special case. An ArchUnit rule can forbid vendor SDK imports in the core.

No. Complexity and differentiation are separate dimensions, and confusing them is a common and expensive mistake. Tax calculation is a good example: GST or VAT rules are intricate and change regularly, but every retailer must apply them in the same way, and customers never choose a shop because its tax engine is clever. That makes it a generic domain, best handled by a specialist tax engine. On a core domain chart, high complexity with low differentiation falls in the buy quadrant. The opposite also happens: a fairly simple pricing rule can be core if it gives a real market edge. Always ask what makes the business win, not what is hard.

Classification decides how much modelling and engineering rigour each part receives. Core domains get rich domain models with aggregates and value objects, a hexagonal or onion structure that keeps business logic free of frameworks, and deep testing including property-based and scenario tests; ShopNow's PromotionStack is an example. Supporting domains can use straightforward layered Spring Boot services, Spring Data REST or even low-code, with integration tests being enough. Generic domains get almost no custom design beyond the adapter and anti-corruption layer around a bought product. Classification also shapes team allocation and boundaries: core teams are senior and stable, and the core is often segregated into its own module or service.

Because markets change, and today's differentiator becomes tomorrow's commodity. Product recommendations were core for ShopNow in 2022, but by 2026 managed ML services made good recommendations available to every competitor, so the area became supporting and investment moved elsewhere. New differentiators also appear, as with the insurer whose rating engine became core once usage-based products mattered. If classification is never revisited, the company keeps investing senior talent in areas that no longer win customers and under-invests in emerging ones. A practical rhythm is an annual review with business leaders, plus a review whenever strategy changes, using a core domain chart or Wardley map to show movement.

I would run a workshop with business leaders and domain experts to list the subdomains and place each on a core domain chart by differentiation and complexity. Then I decide sourcing per type: build the core in-house with the best people, build supporting domains simply or outsource them, and buy generic ones behind anti-corruption layers. Next I compare that with current reality, for example a team maintaining a home-grown identity server, and rebalance capacity towards the core, aiming for more than half of engineering effort there. Each build, buy or outsource decision goes into an ADR with its rationale, and the classification is reviewed annually or whenever strategy changes.