From 32b35c0f39397451d389bcc3f8356df3c12675d5 Mon Sep 17 00:00:00 2001
From: Oliver Davies <oliver@oliverdavies.dev>
Date: Sat, 10 Feb 2024 12:31:07 +0000
Subject: [PATCH] Add daily email for 2024-02-09

Defining boundaries between custom Drupal modules
---
 source/_daily_emails/2024-02-09.md | 49 ++++++++++++++++++++++++++++++
 1 file changed, 49 insertions(+)
 create mode 100644 source/_daily_emails/2024-02-09.md

diff --git a/source/_daily_emails/2024-02-09.md b/source/_daily_emails/2024-02-09.md
new file mode 100644
index 000000000..aaa1b7fcd
--- /dev/null
+++ b/source/_daily_emails/2024-02-09.md
@@ -0,0 +1,49 @@
+---
+title: Defining boundaries between custom Drupal modules
+date: 2024-02-09
+permalink: archive/2024/02/09/defining-boundaries-between-custom-drupal-modules
+snippet: |
+    TODO
+tags:
+    - software-development
+    - automated-testing
+    - architectural-testing
+    - php
+    - drupal
+---
+
+{% block content %}
+I recently made a change to a Drupal project with several custom modules.
+
+As part of the change, there was a method that was no longer being used, so I went ahead and removed it.
+
+There were no tests for this part of the codebase, and the existing tests were still passing.
+
+My change was successfully finished and deployed, including removing the unused method.
+
+A few days later, we noticed cron jobs were no longer running on the website.
+
+The method I'd removed was attempting to be called from within a different module.
+
+Because it no longer existed, it was causing an error and stopping the cron job from running successfully.
+
+When I re-added the method, the cron jobs worked again.
+
+There were no `dependencies` set in either module's .info.yml file, though that would only prevent you from uninstalling either module.
+
+It wouldn't prevent me from deleting code used by another module.
+
+## Here's the thing
+
+This is why I've been [experimenting with architectural testing][yesterday]. To ensure that modules only use their own code and to start enforcing layers within each module.
+
+Then, if I had the same situation again, I'd know straight away that there was an issue and not have to wait for the bug to be deployed to production.
+
+[yesterday]: {{site.url}}/archive/2024/02/08/experimenting-with-architectural-testing
+{% endblock %}
+
+{% block cta %}
+P.S. Do you need immediate access to an expert Drupal Developer? [With my Drupal development subscription][subscription], make unlimited requests for a fixed monthly price in less time than posting to a job board!
+
+[subscription]: {{site.url}}/subscription
+{% endblock %}