96
Views
7
Comments
Solved
Circular dependencies
Application Type
Reactive

Hi all, 

I have a question about circular dependencies between applications and how to fix them. We currently have several Core applications, each containing a CS and BL module. Our Customer_CS module contains data and CRUDs that are used in practically every other module while our Customer_BL module contains high-level business logic and consumes most other CS modules. This causes several circular dependencies between the Customer_Core application and some other Core applications but I'm unsure how to alter the architecture to accommodate these needs. I would like to know what you think is the best solution.

2021-09-06 15-09-53
Dorine Boudry
 
MVP
Solution

that's just not possible to say, it depends on how big it is, how many other parts (i.e. other modules referenced) are involved, if there are clear lines inside the logic, both technically and functionally,  to allow it to be split into several areas...

So if there is a lot in there that involves more than just customer, just rename that one to reflect it is about more than just customer, and put it in it's own application. (which brings us back to my first reply)

2019-01-31 08-54-57
André Costa
Champion

Hi @Remco Jacobs 

To assist you more effectively, could you share a snippet of your current application architecture? It would give a clearer picture of the dependencies and module structure.

Based on your description of the problem, I can think on two potential solution paths that could help you:

  1. Split business logic by function. For example, create smaller BL modules within your Customer Core application that only handle specific domains (e.g., "Customer_Accounts_BL," "Customer_Orders_BL"). This way, each BL module is more focused and less likely to need to depend on multiple other modules. 

  2. Ensure that each of these smaller BL modules only depends on the CS modules and does not cross-reference other BL modules. 

For more guidance on identifying potential architectural issues, you can check this link.


AC

2023-12-04 13-42-05
Remco Jacobs

Hi André, 

I don't think that would quite solve my problem. The thing is that there aren't necessarily circular dependencies between modules but only between applications.

In the image above you can see one of the findings in Discovery. The setup here is that both applications only contain a CS and BL module. The Customer_CS module is used in both Overview_CS and Overview_BL while the Customer_BL module consumes both Overview_CS and Overview_BL. This causes a circular dependency on an application level, not a module level. I hope this is more clear than my previous example.


2021-09-06 15-09-53
Dorine Boudry
 
MVP

Hi @Remco Jacobs ,

we are talking about an application composition problem here, right ? Or do you already have circular references at the module level ??

hard to help without seeing the complete picture, but :

If it is only a problem of application composition, it sounds to me like what you now have in your Customer_BL is bigger than just customer.  How about extract that single BL to a separate core application (and give it an appropriate name that reflects it is not only about customer)

Alternatively, if they all reference each other that intensively, maybe you need to revisit how you have divided up stuff, maybe it is just a bit too granular.

Dorine

2023-12-04 13-42-05
Remco Jacobs

Hi Dorine, 

I've given a bit more context in the reply to André, I hope this helps.

2021-09-06 15-09-53
Dorine Boudry
 
MVP

it looks like your customer and overview are very tightly coupled ? 

At CS level there is only Overview_CS looking at Customer_CS, right?  Maybe a reference attribute in an overview entity to customerid ??  So it follows naturally that Overview_BL also needs to know about customers, maybe both CS and BL.

But why does Costumer_BL have to know about Overview.  Are these a couple of isolated actions, to executed / query on overview when doing certain things on customer. Business functions that affect both customer and overview ?

I would think these are the bits that belong in a 3rd CustomerOverview_BL, in a separate CustomerOverview application.  This one can look at all 4 others, but the others should have zero references to this one.  And maybe you could also bring a couple of BL actions from overview BL to this new module, removing references from OverviewBL to customer.

But this is based on a lot of assumptions, if for example there are not just a couple of actions, but all through customer logic, overview is involved and vice versa, than these should maybe not be separate modules.

Dorine


2023-12-04 13-42-05
Remco Jacobs

Hi Dorine, 

Thanks for your reply. That seems to be the solution I need. We use Customer_BL to run complex business logic that uses many other BL modules. Would it be useful to have a single application for all complex logic or multiple depending on usecase?

2021-09-06 15-09-53
Dorine Boudry
 
MVP
Solution

that's just not possible to say, it depends on how big it is, how many other parts (i.e. other modules referenced) are involved, if there are clear lines inside the logic, both technically and functionally,  to allow it to be split into several areas...

So if there is a lot in there that involves more than just customer, just rename that one to reflect it is about more than just customer, and put it in it's own application. (which brings us back to my first reply)

Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.