CRUD interfaces for services with complex business logic
An interface that is too wide and unspecific either dilutes responsibility or complicates things too much.
For example, CRUD API for services with complex business logic. Such interfaces do not encapsulate behavior. Not only do they allow business logic to leak to other services and blur the responsibility of the service, but they also provoke the spread of business logic - limitations, but invariants and methods of working with data are also now found in other services. Interface User Interface (API) services must implement the logic themselves.
If we try to transfer the business logic to the service without changing the interface significantly, we will get too universal and too complex a method.
For example, there is a ticket service. Tickets can be of different types. Each type has a different set of fields and slightly different validation. Also, the ticket has a status model - the final automatic machine by switching from one status to another.
If the status model will depend on the ticket, then business logic conflicts may occur. First, change the status according to the old status model, and then change the ticket type. Or vice versa?
It turns out that inside the API method there will be a code that is not related to each other - a change in the entity fields, a list of available fields, depending on the type of ticket, and the status model. They change for different reasons and it makes sense to distribute them to different API-methods and interfaces.
If changing some field within the CRUD-methods of the API - is not just a change of data, and the operation tied to the agreed change of the state of the entity, then this operation should be moved to a separate method and not allowed to change directly. If changing an API without backward compatibility is very bad (for public APIs), it is better to think about it at once when designing the API.
Therefore, in order to avoid such problems, it is better to make interfaces small, specific and problem-oriented, instead of universal data-centric.
This (anti)pattern is more common for RESTful interfaces because by default there are only a few data-centric "verbs"-actions to create, delete, update, read. Business-specific operations on entities - no
What can you do to make RESTful more problem-oriented?
First, you can add methods to entities. The interface becomes less restful. But there is such a possibility. We still do not fight for the purity of the race but solve practical tasks.
Antipattern with data-centric API actually refers to rpc interaction as well. For example, the presence of two common methods like editAccount(), or edit Ticket. "Modify object" does not carry any semantic load related to the problem area. This means that this method will be called for various reasons and changed for various reasons.
It should be noted that data-centric interfaces are quite okay if the problem area implies only storing, receiving and modifying data.
Event model
One of the ways to unbind code pieces is to organize interaction between services through the message queue.
For example, if we need to send a welcome-letter to a user in the service during registration of a user, create an application to the CRM for a client manager, etc., it is logical to do not through an explicit call to external services, but in the registration service to put the message "user is registered" in the queue, and all the necessary services will read this message and make the necessary action. Changing the business logic will not require changing the registration service.
Most often they throw not just messages but events into the queue. Since the queue is only a transport protocol, the data interface is subject to the same restrictions as a regular synchronous interface. Therefore, in order to avoid problems with changing the interface and subsequent changes in other services, it is best to make the events as problem-oriented as possible. Such events are also often called subject area events. At the same time, the use of the event model does not usually have a significant impact on the boundaries of (micro) services.
Since the events of the subject area are almost 1 in 1 are translated into synchronous API methods, sometimes it is even suggested that instead of calling the API, the events stream instead of the call stream (Event Sourcing) should be used. It is always possible to restore the state of objects by the flow of events, but at the same time to have a free history. In fact, this approach is usually not very flexible - it is necessary to support all events, and it is often easier to keep the history next to the usual API.
Microservices and productivity. CQRS
In principle, the problem area implies changes in the code related not only to functional business requirements, but also to non-functional ones - for example, performance. If there are two pieces of code with different performance requirements, it means that these two pieces of code may be worth splitting. And usually they are divided into separate services to be able to use different languages and technologies more suitable for the task.
For example, there is a cpu-bound method of calculator in a service written in PHP that performs complex calculations. As the load and amount of data increased, it stopped coping with it. And of course, as one of the variants, it makes sense to make calculations not in php code, but in a separate high-performance c-shell daemon.
As one of the examples of division by services by the principle of performance - division of services into readers and modifiers (CQRS). This division is often offered because readers and writers have different performance requirements. The read load is often much higher than the write load. And the requirements for the speed of response to read requests are much higher than for writing.
The client spends 99% of the time looking for a product, and only 1% of the time in the ordering process. For the client in the state of search is important display speed, and features associated with the filters, different options for displaying the product, etc. Therefore, it makes sense to allocate a separate service, which is responsible for the search, filtering and display of goods. Such a service will most likely work on some ELK, a documented database with denormalized data.
Obviously, the naive division into reading and changing services may not always be good.
Example. For a manager who works with the filling of the commodity nomenclature, the main features will be the ability to conveniently add goods, delete, change and view.
If you separate reading and modification into separate services, we will get nothing from this division, except for the problems when we have to make coordinated changes in the services.