In a no-obligation conversation, we'll figure out together how we can best support you. Concrete next steps, no sales pitch.
Refactorings delivered for
If any of this sounds familiar, domain-driven refactoring is the structured way out.
What started as clean layering has grown into a web of cross-references. A pricing change in checkout triggers tests in reporting.
New engineers need weeks before they can safely commit code. The domain knowledge lives in the heads of three senior devs, not in the code.
Every deployment can have side effects somewhere. You test manually what should be automated. Quarterly release trains are the result.
0%
Downtime during refactor
Strangler-fig pattern and characterization tests keep the system running while we rebuild it.
3-5×
Faster features
Clear bounded contexts and team topology mean multiple teams can ship in parallel, without merge conflicts.
70%
Less onboarding time
Domain language, ADRs and context maps make the system readable, even for new team members.
What your system can feel like when domain boundaries are visible again.
Not every domain is equally valuable. We classify your system along DDD categories and derive build-vs-buy decisions, before you commit budget.
Where you compete
Pricing engine
Market differentiator
Order lifecycle
Customer-experience central
Implikation
Custom development. Best engineers. Highest investment.
What you must do well
Inventory
Business-critical, not a differentiator
Shipping
Standard integration
Implikation
Buy or simple custom build. Proven patterns.
Where standards win
Identity
Entra ID, Azure B2C
Logging & audit
Application Insights, Sentinel
Implikation
Buy or open source. Never build yourself.
In the first workshop, we put business and engineering at the same wall. The result is an event flow that makes bounded-context boundaries visible.
Example: e-commerce order flow
Customer registered
↳ Identity
Item added
↳ Catalog
Order placed
↳ Order
Payment authorized
↳ Payment
Inventory reserved
↳ Inventory
Order shipped
↳ Fulfillment
We build the new system around the old one. Functionality is redirected step by step, the old shrinks until it can be switched off.
Event-storming workshops, context mapping, identifying the key aggregates. Output: visualised domain.
Your time
8-16 h
Our work
2-4 weeks
We define the target architecture and decide together which contexts to extract first.
Your time
4-8 h
Our work
2-3 weeks
Before we touch anything, we lock in current behaviour with characterisation tests. Otherwise nobody knows what breaks.
Your time
2-4 h per week
Our work
ongoing
New functionality goes into the new context. Existing one is redirected piece by piece. Feature flags control the rollout.
Your time
sprint routine
Our work
iterative
Once the new context runs in production, we switch off the old module. Documentation and knowledge transfer included.
Your time
handover per module
Our work
knowledge transfer
Event-storming workshops, context mapping, identifying the key aggregates. Output: visualised domain.
Your time
8-16 h
Our work
2-4 weeks
We define the target architecture and decide together which contexts to extract first.
Your time
4-8 h
Our work
2-3 weeks
Before we touch anything, we lock in current behaviour with characterisation tests. Otherwise nobody knows what breaks.
Your time
2-4 h per week
Our work
ongoing
New functionality goes into the new context. Existing one is redirected piece by piece. Feature flags control the rollout.
Your time
sprint routine
Our work
iterative
Once the new context runs in production, we switch off the old module. Documentation and knowledge transfer included.
Your time
handover per module
Our work
knowledge transfer
Event-storming workshops, context mapping, identifying the key aggregates. Output: visualised domain.
Your time
8-16 h
Our work
2-4 weeks
We define the target architecture and decide together which contexts to extract first.
Your time
4-8 h
Our work
2-3 weeks
Before we touch anything, we lock in current behaviour with characterisation tests. Otherwise nobody knows what breaks.
Your time
2-4 h per week
Our work
ongoing
New functionality goes into the new context. Existing one is redirected piece by piece. Feature flags control the rollout.
Your time
sprint routine
Our work
iterative
Once the new context runs in production, we switch off the old module. Documentation and knowledge transfer included.
Your time
handover per module
Our work
knowledge transfer
DDD isn't just modelling vocabulary. Here are five concrete places where we enforce domain cuts technically, each with documented depth in our blog.
Each context exposes its API through its own APIM product. Versioning, throttling and schema validation enforce the contract between domains.
What DDD describes in code, we do with Terraform via state-mv and resource imports. Old modules shrink, new ones grow, zero-downtime state migration.
Self-hosted GitLab Runner per domain in its own subscription. Teams deploy independently, no cross-team blockers in shared CI.
Own App Registration and Managed Identity per bounded context. No shared service principal, clear RBAC, identity audit per domain.
Stateful domain service on App Service, batch worker on Container Apps, high-scale hot-path on AKS. Choice by workload profile, not by default.
Eight measures we typically apply in the code before working on the domain cut.
Automate building, testing, and deploying the application after every commit using CI/CD servers like Jenkins, GitHub Actions, or GitLab CI, and utilize partial deployments.
Deploy infrastructure resources independent of providers using Infrastructure as Code solutions with Terraform and leveraging AWS, Azure, and GCP providers.
Update programming languages, frameworks, and dependencies to their latest versions to close security gaps, improve performance, and potentially adopt alternative frameworks.
We increase your test coverage during bug fixing and apply the scout rule by revising code and covering it with tests. This includes implementing various types of tests such as unit tests for classes, integration tests for components, and UI tests for the frontend.
Event storming, context mapping and bounded-context hypotheses, the first workshop block.
Together with your domain experts, domain modelers, and developers, we participate in your discussions and workshops to identify the Ubiquitous Language and exclude technical jargon from the discussion.
Which steps are actually justified by domain expertise? We assist you in transitioning the current application to technically superior solutions and reducing the depicted processes to their essence.
After identifying the current situation, we adjust the depicted software processes to the target processes.
Domain insights become a concrete target picture, debatable, reviewable, actionable.
From each identified subdomain, we create a bounded context that will represent the target state. These bounded contexts can emerge from event storming, domain stories, etc.
Based on the existing subdomains of work processes, we create a context map that divides your subdomains into Core, Supporting, and Generic Subdomains. These subdomains support the team in dividing legacy systems into microservices or modular monoliths.
During the division of application responsibilities, we can take on parts of a bounded context as part of the development team and assume technical responsibility for implementation.
To maintain the autonomy of a subdomain, we examine the interfaces and communication paths between bounded contexts more closely.
The technical building blocks behind the DDD patterns above. Each article shows the approach on a real Azure example.
When Azure API Management is the right architectural choice, where it does not belong, and how SKU, networking, and operational decisions affect real-world outcomes.
Read article
Many Terraform projects start lean and end up as monoliths. This guide explains how to migrate Azure infrastructure to modular states, clear module boundaries, and resilient CI/CD governance without downtime.
Read article
This article shows how to securely and reliably run GitLab Runner in Azure and compares Azure Container Apps, App Service, and virtual machines as hosting options.
Read article
Azure App Registrations and Enterprise Applications can be hard to distinguish. In this article I explain the details and dependencies of each Resource Type.
Read article
In this blog post, you'll get a detailed overview of Azure Container Apps, its use cases, and special features. Additionally, the key differences to other container solutions in Azure are highlighted, enabling you to make an informed decision for your cloud architecture.
Read article
A technically grounded architectural classification of Azure Front Door, Application Gateway, and API Management with clear decision criteria, network implications, and real integration patterns.
Read article
Mertkan Henden
Cloud engineering consultant · Heilbronn
Domain-driven refactoring is 20 percent methodology and 80 percent diplomacy. I connect engineering and business in workshops, turn implicit assumptions into explicit bounded contexts and make sure both sides end up speaking the same language.
— Mertkan Henden