0

I'm working in a situation where I have 2 different projects (kind of microservices, but they are still messed up in terms of the tables that each project can access - same domain). But so far, they are accessing (via Azure Functions) what is related to their domains in terms of database perspective (e.g Car domain accesses what is related to the car domain and dealer domain accesses what is related to the dealer domain). So my questions are:

Is correct I say that microservices are split up according to their domains? (Some references about architecture say yes) but looks like it is not a thing we must do. It is only a recommendation. Sometimes we need to consume different domains in each project. What approach we should use to make the communication between the projects? I've heard about direct API calls, use table storage. Does anyone have a different idea about it?

Thank you in advance for any help!

1 Answer 1

1

Is correct I say that microservices are split up according to their domains? (Some references about architecture say yes) but looks like it is not a thing we must do.

There are no absolute right nor wrong ways to define these boundaries, however to get the most benefits, separation is often focused on technical design and coupling.

Ideally the boundaries would leave microservices with one or more entirely self-contained capabilities - i.e. services which give users the ability to 'do something' useful/meaningful with as few dependencies as possible, ideally none.

For example, an authentication capability is a user login which verifies their identity using their credentials. Many systems rely upon stand-alone services (often from a cloud provider) for authentication because that capability on its own is useful; every other part of a system could fail while that service still allows users to log in. Similarly, it can be deployed and scaled independently without affecting the rest of the system, even reused for other systems.

The more dependencies a service has on other services the tighter its coupling and therefore the less value its separation has for your architecture; any change or failure in any one of its dependencies can break some or all of that service's capabilities.

When two or more microservices are so tightly coupled and inter-dependent on each other, their value as separate services becomes highly questionable; at this point it might really be a distributed monolith with very little architectural value beyond a traditional monolith, yet suffering disadvantages in gaining extra complexity with deployment, configuration, infrastructure, project structure, communication...

With that in mind, try to focus on capabilities which can be self-contained as far as possible to decide the boundaries and separation between services, grouping closely-related and tightly inter-dependent functionality together.

Some capabilities and functionality may naturally have a lot of far-reaching dependencies; you might also consider putting this functionality in their own service(s) to avoid "polluting" the other services with unwanted dependencies.

What approach we should use to make the communication between the projects? I've heard about direct API calls, use table storage. Does anyone have a different idea about it?

This depends upon your communication needs and the manner in which functionality within a service is dependent upon other services.

No pattern can be a one-size-fits-all; obviously the best way to minimise complexity is to minimise the dependencies in the first place, and therefore minimise the number of communication paths.

Web API calls via HTTP are a Request/Response pattern, which is likely to be an easy and sensible default to start with. It may be possible to use this pattern for most of your communication paths, which might minimise complexity. Many other patterns exist and technologies which support those patterns.

4
  • Hi Ben Cottrell! Thank you so much for your reply. I appreciate that. So, about your first part of the reply, I agree, I've read some documentation and technical guides where the coupling is always put when considering to choose a way to go. In my case, I'm trying to balance it and see how I can split it to offer the coupling and handling this easily. Your second reply makes sense. I guess for now I'm following more the Synchronous calls since I'm more familiar than using Queues, till I learn it.
    – Marcos
    Commented Oct 26, 2021 at 0:23
  • I have another question, do you follow or recommend using specific documents to create apis? Looks like this is another open world of possibilities. I checked Microsoft documentation already, but to map resources, maybe there is an easier way to do it, etc.. This is the point I'd like more orientation.
    – Marcos
    Commented Oct 26, 2021 at 0:26
  • @Marcos I don't have any particular recommendations, although I prefer to treat API design in a similar manner as UI/UX design; identifying actions and commands a user would want to perform, information and artefacts they'd want displayed, and structures similar to how users might want the UI to be split into pages/tabs/etc. Many apps have Web APIs and endpoints whose usage and structure are closely relatable to the names/concepts/structures/fields that users are familiar with from the app's GUI. (For example: Twitter, Slack, etc.) Commented Oct 26, 2021 at 12:03
  • I see! Thanks! Yeah, that makes sense. I've never thought in terms of UI/UX. But makes sense. What I've been trying to do is pass in the routes, elements I will need to handle, or extract information. Sometimes they are complicated to define, but in general I'm figuring out a way to create a standard to this.
    – Marcos
    Commented Oct 26, 2021 at 22:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.