Defining Bounded Context in microservices

Question

I need clarification on something from someone more experienced to see if I am on right course with this. Following Microsoft's eShopOnContainers microservices approach I got interested in building some small exercise microservices oriented system. But everywhere I look I see same examples using Customers, Products, Orders... and I am not sure if I understand this completely.

For my project I decided to design HR system. Doing some research and got to this. My HR can be divided into these logical parts.

• Recruiting
• Training
• Payroll
• Rewards
• Workforce
• Management
• Time and Attendance
• Staff Welfare
• Development

First I thought these are my Bounded Context's(maybe they are, I am not sure yet) but then I isolated just Recruiting and started thinking about it. I divided Recruiting process in these smaller sub-processes:

1. Identifying(recognizing the need for new employee)
2. Attracting(advertising and gathering candidate applications)
3. Interviewing(collecting candidates data)
4. Selecting(visualizing and comparing data in order to find best candidate)
5. Hiring(converting candidate to employee)
6. Onboarding(creating employee profile, administration...)

I think actually these are my Bounded Context's

1.Identifying - I think of it as a microservice which is subscribed to RecruitingRequestPlaced event. Creating RecruitingRequest with its id, job position, number of candidates, deadline...I also recognise RecruitingRequestCompleted event which determines the outcome. For ex. completed - hired>list of employees. Easy, I am on fire

2.Attracting - In order to collect candidates application I need CandidatesCalatog (I saw analogy with Products Catalog in ms eShop) microservice to hold my candidates who applied for open position. So far so good

3.Interviewing - I found out I can divide this even further in 2 microservices. One would be Interview Schedule calendar appointments kind of service which ties together Time of Interview, Candidate and Interviewer. Second would be Interview Processing, collecting data from interview. Or how I see it, filling some predefined data relevant to job position. At this point I got carried away, I forgot what is my bounded context, my aggregates and what I am I building anyway...Next part really got me confused.

4.Selecting candidates, or how I defined it visualizing collected data, assessing and comparing. And choosing right candidate to hire. First think that crossed my mind is where is my data I collected. It's in Interview Processing microservice. I think I have a problem now. I need to get data from other microservice so my Selecting candidates service makes no sense. Its not good that it depends on Interview Processing.

Should I make it a part of Interviewing microservice? Something crossed my mind if I can put these two things together without any problem then those 2 things aren't my Bounded Context. They belong under same context. But where is actually that line? Can anyone give me his perspective on this. Did I overthink my Recruiting(potential bc) and should it be more simply looked at. Something like:

• Recruiting=Collecting applications, Interviewing candidates and promoting some candidates to Employees

Answer 1

You’re not overdoing it. The world is always more complex than it seems. But you need to keep different views on the problem clearly separate:

• your business requirements are well described in your process analysis. Your first decomposition is very close to what happens in many organizations and seems a good start for thinking about a solution. Your simplified alternative would be oversimplified and lead to unsatisfied users.
• your solution architecture is interesting. But you are in no way obliged to align the microservice architecture on the process design. In fact, finding the right decomposition strategy is one of the key issue in microservice architecture; if the granularity of these services is too fine, they might not be as independently deployable as they should.
• The domain design is yet another view. It’s linked to the two others. But bounded context at a process step level seems to go too far. The ubiquitous language is probably the same for the domain experts across the recruitment process. It’s all about processing candidates.

So keep these views separate. The criteria to set boundaries between bounded context are not the same as the criteria to set boundaries between microservices.

Answer 2

A microservice architecture solves a specific set of problems at the cost of another set of problems. A common advice is to build a monolithic app first, because you don’t know the boundaries of the various contexts well enough to determine which parts to extract into which service. The cost of boundaries in the wrong places can be huge in terms of performance (chatty services) and development time (rebuilding).

In most enterprises, the HRM department is a single problem domain, with a single bounded context in the solution space. Why? Because it’s unlikely that the ubiquitous language within this single department will lead us to multiple bounded contexts and it’s also unlikely that the software for this department is so critical to the business that multiple dev teams are working on it or that it has very high performance demands.

The question mentions that this is a toy project. The thing is that with toy projects it really doesn’t matter. You will learn regardless of which decisions you make. You will feel the pain of wrong boundaries, especially when you add new features after v1. And that’s a good thing, because this experience will help you with real projects.

So my advice would be to simply start developing. Choose the boundaries that feel right, but don’t hesitate to rigorously refactor when you realize they are wrong.