Domain-Based Information Models

Domain-Based Information Models

ignite applies domain-driven design to canonical blueprints of your Business Capability APIs, enabling 3 key unlocks for your global teams. Domain-Based Information Models:

1. Provide a Blueprint for Business Capability APIs

By moving to one system, you’re giving the entire enterprise the blueprints so they can access one API design. 

ignite allows you to quickly build a catalog of Business Capability APIs based on core business functions. These domain-based building blocks are ready to be grouped and assembled whenever the need arises. For each Capability API, ignite’s Domain-Based Information Models contain all of the information pertaining to the API’s own domain, so your teams can view details at a later date, at which they might say, “What did we do here? Oh yeah. That’s cool. Let’s do that again.”

2. Allow Global Visibility with Product-Based Granularity for Rapid Innovation

The common models give you a a head start, ensuring you’re using what’s on the global platform. If anyone else wants to adopt an API lock-stock and barrel, they can take it as is, or extend it. Your global teams are enabled to innovate with completed components, so when it comes time to search for an existing product, the right concept is always visible for plug-and-play because you’re sharing a common business language. You may search a capability and discover it already exists; “Oh, look at this thing in Canada that we did with Marine Insurance, that was really successful. Let’s add that capability to some of our other markets.” With Domain-Based Information Models, you have the granularity and reuse to scale.

3. Avoid Polluting Global APIs with Regional Concerns

Instead of hiring an agency to build a one-off service very similar to one you already have in production, your global team designs your common /Payment Domain Model. From there, you can create your /Payment API Product in ignite, essentially a blueprint or archetype API design, with the canonical details built into it so your global regions can use as is or extend. Say you want to extend a /Payment model, but you don’t want certain regulation limits from one region to affect everyone. Rather than create a version no one else can reuse, you can take the global model and just carve it down for one region’s local purposes. Global consistency… and local relevance.

Learn more about Domain-Based Information Models:

Domain-Based Information Models PDF icon

For more on how enterprise data is visible, shared, and leveraged, visit our Information Architect role page.