Software Engineering Asked by 0xFED5550 on October 29, 2021
We currently handle a well separated monolithic service which handles various ‘contexts’ to help with the separation. I haven’t had any issues so far when dealing with problems that require the creation of a new context since it was simple enough.
Now I’m dealing with a group of entities (3, to be exact) that relate to each other and I’m not sure how to properly organize one of them in the project.
For the example we’ll name them Branch, BranchService, Service.
Branch lives in its own context as does Service, but at the moment I am not sure where to place BranchService. In this case, BranchService is not just an entity to handle many-to-many, it has some information on it’s own that is used around the service.
Since they are relatively coupled, should they be together and share the same context? Or is there an alternative for this case?
I am assuming by Context you mean these are vertical entities and they are logically separated (by assembly boundary or a dependency checker)?
With the limited information I have, can the services be layered? Can BranchService be a parent of Branch and Service and have a domain that concerns the relationships between the two?
Like, you are managing auto repair stores which have different kinds of oil change machines. So you model the stores and the oil change machines and they have their own operations and are directly accessible. You also have a service locator service with reference to the oil change machine service and stores services which can do tasks like finding the nearest location where we can fit another size large oil change machine.
Answered by Martin K on October 29, 2021
Get help from others!
Recent Questions
Recent Answers
© 2024 TransWikia.com. All rights reserved. Sites we Love: PCI Database, UKBizDB, Menu Kuliner, Sharing RPP