Integration II — read before starting your integrations
Ubiquitous Language
- Each business domain should have a common understanding (common sense) between domain experts and technical experts.
Who are domain experts?
They are the people who;
- might have problems as consumer, customer, client, etc.
- identify business problems, such as product managers, analysts, business stakeholders, etc.
- know the ins and outs of a business from past (problems and habits) to future (solutions and roadmap)
- are mostly interested in the functionality
- bring requirements to technical experts
What happens if there is no domain expert?
It’s possible to not have a domain expert. Of course, it’s not an ideal situation but there are things that we can do.
- start to ask the right questions
- visualize problems, systems
- emphatic problem solving
- benchmarking with similar uses cases
- document what you have found and share it with others to get feedback
- PoC
- gather the right people
- try to find key users
- create a common knowledge between people and be sure that they are talking in the same language
Basically, if there is no domain expert try your best to build one. But that doesn’t mean you can’t start the process without a domain expert (most of the time).
Who are technical experts?
They are the people who;
- design systems software architects, solution architects
- write source code software engineers
- check quality QA engineers
- interpret data data analysts, data scientists
- decide system standards, resource usages platform engineer, infrastructure engineer
To simplify, I wanted to mention some technical expert roles and separate them into topics, but in real life, most of them work together very closely and more often than not, there is no specific responsibility separation. They mostly work together and separate in detail.
What happens if there is no technical expert?
- hire one
- receive consultancy
As you can see domain experts and technical experts have different mindsets, visions, approaches, expertise, etc. but they have to reach the same goal and while reaching that goal they need to speak the same language not to get lost in translation. So we call it Ubiquitous Language which basically helps us be on the same page. If all parts of the context speak, use the same language we don’t need to transfer|translate step by step between parts.
Experts speak Ubiquitous Language
Discussions, Code, Tests, Designs use Ubiquitous Language
Where should we use this Ubiquitous Language?
Mostly it’s not enough to solve one problem in organizations. You need to solve different kinds of problems at the same time. Because each problem has its own context it’s not wise to use Ubiquitous Language at the organizational level. So this is the place where we need to understand Bounded Context.
Bounded Context
A Bounded Context is a place where all parts of the system are able to speak, use the same Ubiquitous Language. Defining boundaries is a strategic decision of the organization. Boundaries could get wider or narrower later down the road. It can evolve as your business. I believe it’s best to start with a wider bounded context instead of making it wider later.
Integrating Bounded Contexts
So what I’m focusing on for about 1.5 years is integrating between bounded contexts. I shared some on my first article in a more socio-technical way. In this part, it’ll be more technical.
Context Mapping
I believe it’s always good to visualize systems to have a simple understanding. Also when you start to visualize problems, solutions, systems, architecture…, it becomes easier to see what could be wrong and also helps you to focus on the right place. So Context Mapping is a concept that helps you visualize bounded context integrations.
There are some patterns under Context Mapping;
Open Host Service
In the Open Host Service, Bounded Context exposes functionalities to other systems. API’s is a common example of this pattern. With that API downstream (consumers) can easily integrate with the system. In this pattern it’s good to have well-designed documentation for open host service so downstream (consumers) can easily understand and integrate by themselves.
Conformist
In the Conformist pattern, downstream (consumer) must conform the contract of upstream (supplier) contracts. We mostly face this pattern on external integrations that we need to follow our vendor's standards.
Anti Corruption Layer
In Anti Corruption Layer pattern, downstream(consumer) don’t need to conform everything that upstreams (suppliers) offer inside their bounded context. So with the anti-corruption layer pattern consumers are able to do some translations without changing their context. It’s useful when there are legacy systems that you need support within new systems. It’s also useful when your upstream (suppliers) has no mature system yet so things are not clear so you need to cover some on Anti Corruption Layer.
Shared Kernel
In Shared Kernel pattern, two bounded contexts share some common needs. It can be a code, event, database. In this pattern, they need to work collaboratively because they have common dependencies. For example it can be an aggregator database/service that these two bounded contexts need to take use same data.
Customer / Supplier
Customer / Supplier pattern, I think this is most common pattern that we face in our daily life. In this pattern customer has requirements from supplier so to achieve this integration supplier needs to be ready first. They can work independently at the beginning but at the end they need to have some touch points to start integration.
Partnership
In partnership pattern, I believe this is also very common in the current IT industry. We need to have sync communication on this pattern to achieve integration. In this pattern bounded contexts mostly achieve to a common goal of business so communication and collaboration is kinda important. For example 1st bounded context might be a place for calculations and 2nd bounded context might be a place to apply validations for that calculations so they need to have a handshake on that.
There are also 3 other patterns on Context Mapping but I believe these are not part of Bounded Context Integrations;
Published Language
Published Language is a pattern that two bounded context has common language between them. Mostly it’s documentation where systems understand their context from that documentation.
Separate Ways
Separate Ways is a pattern that is obviously not integration between bounded contexts. On this pattern bounded contexts achieve their goals separately. Which might create duplications, data inconsistency, reworks, etc.
There is also a Big Ball Of Mud but I’ve already wrote an article for that so you can read this article.
So these are the patterns I’d like to follow within integrations. At the beginning, it might be hard to map contexts but when you understand these patterns it’ll be really easy for you to integrate with the contexts that you need to work with. I believe these patterns will give you more vision about what you are doing as technical experts. These are part of Strategic Design in the next part we’ll be talking about Tactical Design. Please do not be afraid to get into Domain Driven Design, things will become easier for you when you understand there are patterns that are already defined so please use them instead of discovering them again.
