I'm working on a project with web services, and I've been structuring things where:
I've recently been learning about micro services. In hindsight, I'd want to split the service in multiple services each covering a specific domain of the business. What should I have done with the library? I'm thinking I could:
- Keep the monolithic library that all the services use
- Split the library into multiple pieces (again, based on business domains)
- Each library includes all the interfaces it interacts with (which means redundancy between the libraries)
- Glue libraries that cover the gap or boundary between two domains
I don't like the monolithic library, but I can't decide how I would've handled splitting it up. I don't like idea of duplicating the model code, but I don't like the idea of glue libraries either—it seems unintuitive; not as simple as it should be.
How can you separate a monolith into domain-driven libraries without duplicating interfaces and still keep dependencies simple?
At present, I'm thinking:
- A single glue library containing all the interfaces and business logic
- Multiple domain-driven libraries containing implementation and data access
- Services mostly translate to and from the glue
Is this the best compromise? I'm worried the glue library is just a mini-monolith.