Post History

**Important note**: this is primarily based on personal fairly long experience with monolithic architectures and limited microservice-based architecture combined with others' experience with microservice-based architecture

Based on your rather vague requirements and the data volume indicated in the comments, I suggest:

## Modular Monolithic Architecture

This can be a good way to start a project even if it will eventually need some microservices (for scaling reasons mostly). [This article](https://www.thoughtworks.com/insights/blog/microservices/modular-monolith-better-way-build-software) provides a very good introduction about this architecture, so I will only add some highlights here:

- modules should have clear boundaries. This avoids what you have noticed in legacy systems (messy/disastrous) and can be achieved by using events or a CQRS-like architecture, thus avoiding a direct coupling between modules.
- easier deployment
- simpler infrastructure
- less network overhead (mostly happens in memory)
- easier to reach data consistency, since a transaction does not span to multiple services
- allows for a module to be migrated should it have special scalability needs, require development by another team or it requires to be rewritten in another framework

[This article](https://medium.com/design-microservices-architecture-with-patterns/microservices-killer-modular-monolithic-architecture-ac83814f6862) goes deeper into the topic.

For the particular architecture at the module level, I recommend using a clean architecture, as shown in [this article](https://medium.com/design-microservices-architecture-with-patterns/design-clean-architecture-for-e-commerce-applications-with-step-by-step-297b331cdf41).


### Upfront separation

If you know that one module of the application has special requirements, it makes to define it as a special service. For example, it is very likely that the employee module should have much more strict security constraints than another module due to the nature of its data (e.g. encryption at rest, encryption in transit).

It would make sense to define it as a separate service with its own small database. 

### Sacrifice some DRY in order to favor decoupling 

This means that you should avoid reusing business logic between the project types unless it is something very generic like an economical indicator that has a universal formula or similar. This ensures that each project type can evolve independently and reduces the likelihood of getting the "mess" found in the legacy projects.

[This article](https://paulallies.medium.com/the-dry-principle-in-programming-why-its-not-always-the-best-choice-5ea73b3f09f9) explains in very simple terms how sacrificing DRY within reason can lead to a better result.

Broadly speaking this approach also increases stability:

- with business logic sharing: a change request makes you wonder how other project types are affected
- with less/no business logic sharing: a change request affects only the changed project type and you know for certain that other types are not affected. The worst case is that the other types have an old, but stable business logic, as opposed to a possibly broken business logic.