We're currently using the Apache Camel Java DSL to structure our application, but I guess this question can mostly apply to any DSL in general.

Now, amongst our developers, we are divided on two polar opinions as to how to structure our codebase:

Approach 1:

Use the DSL as rarely as possible, and stick to using plain Java classes for representing our application logic. Our code is driven by the DSL, so the idea is to delegate the processing to a Java class as soon as possible, so that the rest of the logic is completely independent of the DSL.

Pros:

• Your code is mostly decoupled from the framework. Useful if you want to replace the framework with something else.

Cons:

• You are not making full use of the DSL, which abstracts out so much boilerplate code for you. You might as well not use the DSL at all in the code, and it would not make any difference.
• (Specific to Apache Camel) Since the DSL is provided by a framework, the moment you delegate the application logic to a Java class, you cannot use the DSL again within any of the code that is called by the class. So if you want to use a functionality that the DSL provides within a Java class, then you would have to implement it yourself.

Approach 2:

Use the DSL to structure the 'backbone' of our application logic. The actual business logic operations would be defined in modular plain Java methods (i.e Camel processors), which would be called through the DSL.

Pros:

• You are making full use of the DSL. If you want to execute an operation that the DSL completely abstracts out for you, you can do it without reinventing the wheel.

Cons:

• Code is tightly coupled to the framework. Tomorrow if you want to replace the framework, you would need to rewrite the application
• It would take more effort to onboard new developers.

So my question is, based on your experiences, which approach would you all favor in the long run, and why? I don't have a specific criteria on which to evaluate either approaches, we were considering anything that leads to cleaner code and better project maintainability in the long run, as the criteria when discussing amongst ourselves.

We're currently using the Apache Camel Java DSL to structure our application, but I guess this question can mostly apply to any DSL in general.

Now, amongst our developers, we are divided on two polar opinions as to how to structure our codebase:

Approach 1:

Use the DSL as rarely as possible, and stick to using plain Java classes for representing our application logic. Our code is driven by the DSL, so the idea is to delegate the application logic processing (routing, integration logic, etc.) to a Java class as soon as possible, so that the rest of the application logic is completely independent of the DSL.

Pros:

• Your code is mostly decoupled from the framework. Useful if you want to replace the framework with something else.

Cons:

• You are not making full use of the DSL, which abstracts out so much boilerplate code for you. You might as well not use the DSL at all in the code, and it would not make any difference.
• (Specific to Apache Camel) Since the DSL is provided by a framework, the moment you delegate the application logic to a Java class, you cannot use the DSL again within any of the code that is called by the class. So if you want to use a functionality that the DSL provides within a Java class, then you would have to implement it yourself.

Approach 2:

Use the DSL to structure the 'backbone' of our application logic. The actual business logic operations would be defined in modular plain Java methods (i.e Camel processors), which would be called through the DSL.

Pros:

• You are making full use of the DSL. If you want to execute an operation that the DSL completely abstracts out for you, you can do it without reinventing the wheel.

Cons:

• Code is tightly coupled to the framework. Tomorrow if you want to replace the framework, you would need to rewrite the application
• It would take more effort to onboard new developers.

So my question is, based on your experiences, which approach would you all favor in the long run, and why? I don't have a specific criteria on which to evaluate either approaches, we were considering anything that leads to cleaner code and better project maintainability in the long run, as the criteria when discussing amongst ourselves.

We're currently using the Apache Camel Java DSL to structure our application, but I guess this question can mostly apply to any DSL in general.

Now, amongst our developers, we are divided on two polar opinions as to how to structure our codebase:

Approach 1:

Use the DSL as rarely as possible, and stick to using plain Java classes for representing our business logic. Our code is driven by the DSL, so the idea is to delegate the processing to a Java class as soon as possible, so that the rest of the logic is completely independent of the DSL.

Pros:

• Your code is mostly decoupled from the framework. Useful if you want to replace the framework with something else.

Cons:

• You are not making full use of the DSL, which abstracts out so much boilerplate code for you. You might as well not use the DSL at all in the code, and it would not make any difference.
• (Specific to Apache Camel) Since the DSL is provided by a framework, the moment you delegate the business logic to a Java class, you cannot use the DSL again within any of the code that is called by the class. So if you want to use a functionality that the DSL provides within a Java class, then you would have to implement it yourself.

Approach 2:

Use the DSL to structure the 'backbone' of our business logic. The actual operations would be defined in modular plain Java methods, which would be called through the DSL.

Pros:

• You are making full use of the DSL. If you want to execute an operation that the DSL completely abstracts out for you, you can do it without reiventing the wheel.

Cons:

• Code is tightly coupled to the framework. Tomorrow if you want to replace the framework, you would need to rewrite the application
• It would take more effort to onboard new developers.

So my question is, based on your experiences, which approach would you all favor in the long run, and why? I don't have a specific criteria on which to evaluate either approaches, we were considering anything that leads to cleaner code and better project maintainability in the long run, as the criteria when discussing amongst ourselves.

We're currently using the Apache Camel Java DSL to structure our application, but I guess this question can mostly apply to any DSL in general.

Now, amongst our developers, we are divided on two polar opinions as to how to structure our codebase:

Approach 1:

Use the DSL as rarely as possible, and stick to using plain Java classes for representing our application logic. Our code is driven by the DSL, so the idea is to delegate the processing to a Java class as soon as possible, so that the rest of the logic is completely independent of the DSL.

Pros:

• Your code is mostly decoupled from the framework. Useful if you want to replace the framework with something else.

Cons:

• You are not making full use of the DSL, which abstracts out so much boilerplate code for you. You might as well not use the DSL at all in the code, and it would not make any difference.
• (Specific to Apache Camel) Since the DSL is provided by a framework, the moment you delegate the application logic to a Java class, you cannot use the DSL again within any of the code that is called by the class. So if you want to use a functionality that the DSL provides within a Java class, then you would have to implement it yourself.

Approach 2:

Use the DSL to structure the 'backbone' of our application logic. The actual business logic operations would be defined in modular plain Java methods (i.e Camel processors), which would be called through the DSL.

Pros:

• You are making full use of the DSL. If you want to execute an operation that the DSL completely abstracts out for you, you can do it without reinventing the wheel.

Cons:

• Code is tightly coupled to the framework. Tomorrow if you want to replace the framework, you would need to rewrite the application
• It would take more effort to onboard new developers.

So my question is, based on your experiences, which approach would you all favor in the long run, and why? I don't have a specific criteria on which to evaluate either approaches, we were considering anything that leads to cleaner code and better project maintainability in the long run, as the criteria when discussing amongst ourselves.