When starting a management system for a company, the architecture question that comes up first is usually: split it into many small services, or keep one block? The short answer: for most internal management systems, one well-organised block is the right choice — and the interesting part is the phrase "well-organised".

The real price of microservices

Microservices solve a specific problem: several teams need to release independently of one another, or some parts of the system have very different scaling needs from the rest. If your company is in neither situation, you pay the full cost and receive none of the benefit:

• Distributed transactions. Once one business operation touches two services, atomicity is gone; you must handle compensation, intermediate states and half-finished situations.
• Debugging gets much harder. A request crossing four services needs centralised tracing, or you spend hours just locating where the error happened.
• Reference data gets duplicated. Employee and customer lists are copied into several places, and then drift apart.
• Operations cost more. More services means more pipelines, more configuration, more things that can break at midnight.

A monolith is not the same as a mess

The problem with old large systems was not that they were one block, but that there were no boundaries inside. A single block can still be divided into clear business areas, each with its own data model, talking to the others only through defined interfaces.

A common way to organise this in the .NET world:

• Clear layering: the business domain does not depend on infrastructure; the application layer holds the flow; the infrastructure layer holds data access and external services.
• Folders by feature, not by file type. One folder holding a complete business operation reads far better than three folders holding all commands, all queries and all models.
• Separate commands from queries. The write path needs business rules and transactions; the read path needs to be fast and flexible. Forcing both through one model is the origin of bloated queries.

When splitting a service does make sense

A few cases are clearly worth it, even in a small system:

• Heavy background work: large report exports, image processing, scheduled synchronisation. Split it out so one heavy task does not slow the user interface.
• The public-facing part: an API gateway for a website or mobile app, with security and rate-limiting needs entirely different from the internal side.
• Volatile third-party integrations: wrap them behind their own layer so a partner's protocol change touches one place only.

Note that all three split for a concrete operational reason, not for "modern architecture".

A pragmatic order of priorities

Correct boundaries matter more than the number of services. One block with clear boundaries can always be split later; many services with wrong boundaries are nearly impossible to merge back.

The sequence to follow:

• Start as one block, with modules divided by business area from day one.
• Forbid cross-access into another module's tables — the most important boundary, and the easiest one to break.
• Measure before splitting: without data showing a bottleneck, the split is guesswork.
• When you split, split along a line that already exists in the code; do not draw a new one.

Signs that the boundaries are failing

• Changing one business rule requires opening several unrelated modules.
• Queries join across three or four different business areas.
• A small change to a master list breaks reporting in a way nobody predicted.

None of these is cured by splitting into services. Splitting a tangled block produces tangled services with a network in between. Fix the boundaries first, then talk about separation.