2

We are currently splitting up our Intranet monolith into multiple (Micro)services. The layout in itself is already finished and we have decided to split them up in a way that there is only ever one service connecting to a different outside service. One of these services, for our news and companywide calendar has to connect to confluence.

Now my problem is how would one want to name this service? Should it be named "News & Calendar" or "Confluence connector" (or similar).

Or should we use a different service architecture all together? Split the single service into a Confluence Connector which handles the authorization and forwarding and have two different services for News and Calendar? (for a total of three)

Improve this question

1 Answer 1

Reset to default
1

Describe to me the role of this service. What is the most accurate summation of its responsibilities? Not just of the things it has implemented today, but also factoring in any future features that it would be taking on.

"News & Calendar"

I understand from this that this services will provide all news- and calendar-related data. I do not understand where this data will come from. It could be from its own local database, it could be generating completely random content every time, it could be getting it from Confluence, or it could be getting it from a multitude of external services.

"Confluence connector"

I understand from this that this service will serve the data that comes from Confluence. It may not be returning all data from Confluence, but if we're going to need to fetch additional data from Confluence in the future, this service will be the one providing it.

Pick the name which most accurately reflects the interpretation, because that's exactly what the goal of naming something is: ensuring that the name adequately describes what you can expect from the thing.

we have decided to split them up in a way that there is only ever one service connecting to a different outside service

It seems "Confluence connector" is the correct name then.

"News & Calendar" might coincidentally also be an accurate summation because that's the only data you currently get from Confluence, but there's no guarantee that this will remain correct in the future.

  • What happens if you no longer fetch the news from Confluence, but from Google, which (by your own definition) would have to come from a different microservice ("Google connector") which connects to the different external source (Google)?
  • What happens if you now also fetch the wiki page content itself from Confluence?

In either case "News & Calendar" will no longer be an accurate name for your microservice, but "Confluence connector" will still be correct.

Improve this answer
3
  • Thanks a lot! Another quick question; would you split it up into three different services (as described in the question) or would keep it as one?
    – SirHawrk
    Jun 3 at 8:22
  • 1
    @SirHawrk: The amount of microservices you need is very much influenced by the size and scope of each individual microservice's role. Purely theoretically, you'd have a microservice for each bounded context (News, Calendar) and each external data source (Confluence, Google), but the added overhead cost might not be worth it if we're really only talking about a single straight forward fetch from the API. I can't answer this without knowing both your current size and complexity, and what you expect the future to hold.
    – Flater
    Jun 3 at 8:25
  • I love that you added the “in the future” perspective. Microservice or not, a name should tell you what does and doesn’t belong inside.
    – candied_orange
    Jun 3 at 11:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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