API Management

Apply Domain-Driven Design to Your Canonical Model (2 of 2)

The Canonical Model Oasis

This is part 2 of a series on adaptable canonical model management. In part one we discussed the two polaric states of a Canonical Data Model that we typically see in an enterprise setting; too much or not enough. Here, we’ll cover the ideal state and how our ignite platform provides many critical features to get there.

A quick refresher: Domain-driven design (DDD) is “an approach for software development that solves for complex needs by connecting the implementation to an evolving model.” (DDDComunity) It is based on the following 3 key principles:

  • Expert involvement
  • Ubiquitous language
  • Iteration and refinement

 

Domain Driven Design advocates modeling based on the reality of business as relevant to our use cases. As it is now getting older and hype level decreasing, many of us forget that the DDD approach really helps in understanding the problem at hand and design software towards the common understanding of the solution. When building applications, DDD talks about problems as domains and subdomains. It describes independent steps/areas of problems as bounded contexts, emphasizes a common language to talk about these problems, and adds many technical concepts, like entities, value objects and aggregate root rules to support the implementation.”
Domain-Driven Design for Services Architecture

 

1. Combat a wild west situation by applying automation & domain-driven design to the canonical model

In the “wild west canonical” situation we’ve defined in our last post, where there is no single source of truth, there is little light for providers and consumers on where to begin. Our ignite platform brings value here by ensuring that no matter who you are, you can literally see and select from the source.

 

Use Case 1A: Avoiding duplication and knowing where to start

Avoiding duplications means knowing what other lines od business have built! Having one single-source-of-truth helps to break the silos.

Let’s say an API provider wants to build a “Claims” API. Starting out, that provider might not know that another developer from a different region or domain has already created a “Claims” service — they’ve already gathered the right requirements, business logic, NFRs and SLAs — it’s a beautiful, well-designed service. What is to stop that API provider from going through the same process?

ignite solves for this by first providing a highly-visible design catalog that is self-serviceable for any user — this is a critical feature for all users, especially external API consumers who might be new to what you have in store, or business roles who are less technical.

 

 

Applying domain-driven design to canonical models

Applying domain-driven design to canonical is a core piece of the innovation puzzle.

Because the platform applies domain-driven design to canonical models, users can go to a capability tile view to see services by domain, and there they will have access to everything that has ever been built by each domain, effectively connecting your organization across regions and lines of business.

Because ignite is tied to the lifecycle, everything, even changes and new versions, get cataloged in ignite. Building within the catalog also allows ignite to notify a user when it discovers a pattern in what that user is building — it can then point them to an existing service to keep them from reinventing the wheel.

From there, the user can make the call on whether to reuse what’s existing, or extend a part of it. If they have to create from scratch — that’s fine! But the point is, at least they’re creating from scratch with the blessing that this is the first time you’re creating your specific service — there’s no duplication.

 

Use Case 1B: Converting a service to a new format

Another problem — what if that “Claims” service they found is a SOAP service and our provider needs a RESTful API?

To that end, the platform offers custom accelerators to convert SOAP to REST, to event, to message, and vis-a-versa. It also allows the option to import a service and strip it to its design blueprint for future use, then generates code templates for whichever format required. We find that automating this part of the process eliminates a great deal of manual labor (and thereby human error) while keeping all resources mapped to their proper systems.

 

2. Tackling a rigid canonical: Canonical decoupling, importing, and refactoring by domain (DDD)

In the canonical canyon, there is a model in place… but it’s extremely rigid, and constantly changing versions mean bottlenecks in every direction. Sound familiar?

 

The challenges in “canonical canyon”

A canyon splits a path in two.

When you have everyone using one model, problems snake out of every overturned rock (okay, I’ll drop it with the canyon metaphor): 1. Consumers need to know where everything is to use it and innovate, but have no time to learn the manual, leaving data modeler (s) to address a million questions. 2. These models are usually not very good candidates for RESTful, which creates huge inefficiencies for your APIs; the models from SOA days are great for services but RESTful APIs require decoupling.

In this scenario, there is a model, but it’s not very useful. You often need governance around it to remove bottlenecks (if this sounds like an oxy-moron, see Governance-First Development). There’s also 3. the versioning issue – if you have one model and 20 groups using it, then when someone wants to make a change, you now have to keep track of that change and see what impact it’s going to have on everyone else, or if it’s backward compatible, etc…

When you break this model apart and create domain-based models, you remove the dependency on versions. So it’s very important to analyze how you want to decouple it, who’s going to use it, how often it needs to change; it’s all part of governance. Before that, you have to make the decision of how you’re going to make this work for everyone using the models.

 

Decoupling the canonical

Decoupling canonical -- one side of a canyon is but a cliff.

What ignite allows them to do, first you’ll be able to bring in your model and then we allow you to search and discover your own capabilities. We help with “flattening or decoupling” — you can use our platform to analyze the situation and figure out how you want to change it so the opportunities are open to everyone using them. We turn your model (or non-model) into a RESTful model that is easier to operate in.

We allow you to look at the model, analyze and create core components grouped by specific functions within the model, so your developers and consumers can clearly see each grouping. They don’t have to drill down into all of these layers to figure out how everything is related, and they can conduct a simple search by the grouping. ignite helps you to search, rearrange, and group, for greater usability when you get to the design of APIs and services.

We have replicated a logical model with our platform, so your organization stays aligned; it’s all defined for consumers so they don’t have to worry about glossary definitions, etc. ignite helps move that responsibility to an API producer, so you have a simplified layer for the API consumers that gives them just what they need to understand how a service needs to be built.

Ideally, you don’t want to make all of the decisions up front — if you do, you’re not giving your developers, producers, and consumers the flexibility they need to work with. We give you a way of creating that layer.

 

Information model must-haves

A good, visible information model breaks silos! Two figures climbing up a rocky path with a flag.

  • Accessibility. You want it to be used. Otherwise it’s a bit pointless. With ignite, rather than pushing at documentation, all you have to do is click and drag. This is quite compelling for not just IT, but even business roles who might want to act as citizen developers and put ideas directly into production.
  • All data should be data-in-motion. ignite enables the transfer of just a small amount of data — just the data needed, so data sharing is lightweight on your systems.
  • Must break silos! Years of mislabeled, point-to-point integration makes much of these backend legacy systems hard to replace, and therefore, much of the data is all but buried.
  • Lineage. So the model can move forward. As you take feedback, your understanding changes the model. For instance, take a service called “Client ID” Perhaps one team says, consumers aren’t going to relate to that, so let’s call it XYZ locally. As the model owner, that’s incredibly useful to see how its being used (in different circumstances).
  • Data Security. Embedding the right security directly into the lifecycle so the correct security standards are always used.
  • Governance. The more baked-in, the better — data validation fields ensure an existing option is selected so your developers are always building along a formal workflow. With everything happening within one place, you’re getting incredible views of how many of your services check the boxes; what’s in production, proper security is being used, the right compliance are in place — and an audit can be conducted in moments, not months.

Canonical success! Caped figure on top of a mountain.

 

 

Our ignite platform started as a canonical model management tool — it’s something we do quite well. And because your model is at the heart of your entire organization’s body, it’s especially key that these flexible mappings are now extended to every stage of your service development lifecycle as well.

Want to learn more about ignite? To request a personalized demo, reach out today.

 

Related Articles

Close