1.3 KiB
If you see yourself pushed events back and forth between service boundaries, creating a kind of data synchronization process, then you need to re-evaluate your service boundaries! Engines
Engines were kind of a big deal at one time. Think of search engines or rules engines. Now we say search service or rules service. The important aspect of an engine is that there is lower-level framework-type part that is the engine itself. Then, there are bits and pieces that we plug into the engine. These bits and pieces are not necessarily coupled to each other. The engine doesn't encourage dependencies that are plugging into it. Sometimes when you have complex and ever-changing rules you actually need an engine instead of a domain model. For example, a pricing domain model might be influenced by data from many services. A domain model would then break all of your service boundaries. Pricing, risk, search are common examples of the engine pattern. Litmus test: take the name of the problem, append the word "engine" and then google it. If you can't find anything about it, it might not be a good idea. If you do find stuff, you might be able to use an engine to solve the problem. Engine code lives in IT/Ops. Engines can listen to events across service boundaries and make decisions based on the aggregation of the data of those events.