uuid: - value: 20010c04-2f30-4772-9041-6f7e836158f8 langcode: - value: en type: - target_id: daily_email target_type: node_type target_uuid: 8bde1f2f-eef9-4f2d-ae9c-96921f8193d7 revision_timestamp: - value: '2025-05-11T09:00:18+00:00' revision_uid: - target_type: user target_uuid: b8966985-d4b2-42a7-a319-2e94ccfbb849 revision_log: { } status: - value: true uid: - target_type: user target_uuid: b8966985-d4b2-42a7-a319-2e94ccfbb849 title: - value: 'Why write framework-agnostic code' created: - value: '2024-03-05T00:00:00+00:00' changed: - value: '2025-05-11T09:00:18+00:00' promote: - value: false sticky: - value: false default_langcode: - value: true revision_translation_affected: - value: true path: - alias: /daily/2024/03/05/why-write-framework-agnostic-code langcode: en body: - value: |

Yesterday, I wrote about writing layers in your application code and the benefits of loosely coupled code.

Something else you can do with this approach is to write framework-agnostic code.

By writing your business logic in code that isn't tied to a specific framework or CMS, with a small adapter layer, you can upgrade to a newer version of the framework, such as Drupal 7 to 10, or a different framework, keep most of the code the same and only update the parts that connect the business logic and the framework.

This is something that Commerce Guys (now Centarro) did when creating Drupal Commerce 2.0.

The logic around addressing, tax, etc., was released in separate PHP libraries, each with its own release cycle and reusable logic.

This meant the Drupal modules were much smaller, and other eCommerce systems and frameworks could use the agnostic libraries.

It's something to consider when writing your next Drupal module.

It's something I did recently and have done on client projects previously, and it can be a good approach.

format: full_html processed: |

Yesterday, I wrote about writing layers in your application code and the benefits of loosely coupled code.

Something else you can do with this approach is to write framework-agnostic code.

By writing your business logic in code that isn't tied to a specific framework or CMS, with a small adapter layer, you can upgrade to a newer version of the framework, such as Drupal 7 to 10, or a different framework, keep most of the code the same and only update the parts that connect the business logic and the framework.

This is something that Commerce Guys (now Centarro) did when creating Drupal Commerce 2.0.

The logic around addressing, tax, etc., was released in separate PHP libraries, each with its own release cycle and reusable logic.

This meant the Drupal modules were much smaller, and other eCommerce systems and frameworks could use the agnostic libraries.

It's something to consider when writing your next Drupal module.

It's something I did recently and have done on client projects previously, and it can be a good approach.

summary: null field_daily_email_cta: { }