Hi,

Could someone please explain in simple words, what is the rationale for splitting core modules into CS (for CRUD only, I would actually call it DL for data layer) and BL (for any logic above which is more than just CRUD).

This is a practice enforced now on our project by architects, and even though I admit their knowledge and experience, I still can't understand the benefit of this. I can list several obvious cons, but can not tell a single pro. I really want to understand what this is about, and maybe finally agree with this approach.

Hi! 

I see one, business logic is independent from which database you use,in a big project have the 2 in separate eSpaces can be important.


Hi,

Igor, why don't you ask the architects on your project to explain this to you? It should not be a problrm for them explaining the reasoning behind their Architectural guidelines.

Regards,

Daniel

Hi Igor,

Usually, CS and BL modules are both part of the Core Layer of the 4 Layer Canvas.

CS (refers to Core Services) is usually where you define the entities for your concepts. For instance, Customer_CS should be the module where you define the entities that support Customer information. Also, like you said, these modules include CRUD actions.

BL (refers to Business Layer) is usually where you define the logic for your applications. They should be an upper sub-layer of the Core Layer. This means that these modules can aggregate several calls to CS modules.


Imagine that you have a functionality that affects 2 or more different concepts, but the concepts are not strongly connected. So, they should be in separated modules and, because of that, they have different life-cycles. This BL sub-layer will allow you to implement a logic that aggregates these different CS modules.


This split is not entirely necessary, it really depends on the projects. But I believe the reason they did it was just because scalability. Other befenit is clearly the management of the dependencies between the modules.


If you aggregate all of the logic inside CS modules, this will lead to CS modules depending on other CS modules, leading to something like this:

This means that if you want to migrate UI1 to other environment, even though you're using only logic from CS1, you will need to migrate CS2 as well.


However, if you have BL modules, you can have something like this:

This means that if you want to migrate UI1, you don't need to migrate CS2 or CS3; you only need CS1.


Hope this helps you.


Kind regards,

Rui Barradas

Rui Barradas Thanks, this makes sense, and this is very good explanation.

However, the main thing I can't accept is that this split has to go between entities and logic. It rather has to be logical or conceptual separation. In your example, you could keep all the names CS, and allow entities to appear in any of them (if needed). This would still fix the issue in the same manner, only that would be more "righteous" and more stable way. Simply cutting out logic from entities does not guarantee to even solve the particular dependency (but it makes it more possible, yes).

To me this looks like an attempt to find generic solution for all possible dependency issues, rather than treating each case specially.

Hi again Igor,

For me, that separation only makes sense if it is logic vs concept. Because logic can aggregate several concepts, meaning that one logic action can obviously impact different concepts. And each concept should be independent and have a different life-cycle (unless we're talking about strongly connected concepts).

But a concept is directly related to the entities that support that concept.

Of course, there would be another ways to architect this. But yes, they are probably trying to find a solution that prevents all kinds of dependency issues. Like I said before, scalability :)


Kind regards,

Rui Barradas