📖 چکیده

در مهندسی نرم‌افزار سنتی، پیاده‌سازی منطق کسب‌وکار (Business Logic) در دل کد اپلیکیشن یک اصل بنیادین است. اما همین اصل، وقتی از دریچه مهندسی داده به آن نگریسته شود، به یک «بدهی تحلیلی» (Analytical Debt) عظیم تبدیل می‌شود.

💡 راه‌حل: ما یک راه‌حل معماری مدرن مبتنی بر لایه تبدیل داده (Data Transformation Layer) و ابزارهایی مانند dbt ارائه می‌دهیم که منطق کسب‌وکار تحلیلی را از کد اپلیکیشن استخراج کرده و آن را به یک دارایی متمرکز، نسخه‌بندی‌شده، قابل تست و تحت حاکمیت تبدیل می‌کند.

🔴 ۱. آناتومی یک تعریف پنهان: مهندسی معکوس «مشتری فعال»

بیایید یک قطعه کد شبه-جاوا را که منطق «مشتری فعال» را در یک سرویس کاربری پیاده‌سازی می‌کند، بررسی کنیم:

public class UserService {
    public boolean isActive(User user) {
        // Rule 1: Must have logged in within the last 30 days
        Instant thirtyDaysAgo = Instant.now().minus(30, ChronoUnit.DAYS);
        if (user.getLastLoginDate().isBefore(thirtyDaysAgo)) {
            return false;
        }

        // Rule 2: Must have made at least one purchase
        if (orderRepository.countByUser(user.getId()) == 0) {
            return false;
        }

        // Rule 3: Must not have an open high-priority support ticket
        if (supportTicketRepository.hasOpenHighPriorityTicket(user.getId())) {
            return false;
        }

        return true;
    }
}

✅ از دیدگاه توسعه‌دهنده اپلیکیشن

این کد کاملاً منطقی و کارآمد است.

❌ از دیدگاه متخصص داده

این یک کابوس است:

⚠️ نتیجه: این مشکلات، ساختن هرگونه تحلیل طولی (Longitudinal Analysis) یا مدل پیش‌بینی قابل اعتمادی را تقریباً غیرممکن می‌سازد.

🟠 ۲. راه‌حل معماری: استخراج منطق به لایه تبدیل داده

راه‌حل، پذیرش این واقعیت است که منطق کسب‌وکار عملیاتی با منطق کسب‌وکار تحلیلی متفاوت است:

بنابراین، ما باید منطق تحلیلی را از کد اپلیکیشن استخراج کرده و آن را در یک مکان متمرکز و declarative پیاده‌سازی کنیم: لایه تبدیل داده در انبار داده.

🛠️ ابزار منتخب: dbt (Data Build Tool)

dbt به ما اجازه می‌دهد تا این منطق را به صورت کد SQL بنویسیم، آن را در Git نسخه‌بندی کنیم، تست کنیم و مستند سازیم.

📋 فرآیند پیاده‌سازی

گام ۱: استخراج داده‌های خام (EL)

داده‌های مورد نیاز (لاگین‌ها، سفارشات، تیکت‌های پشتیبانی) از پایگاه‌های داده اپلیکیشن استخراج و در انبار داده بارگذاری می‌شوند:

گام ۲: پیاده‌سازی منطق به صورت Declarative با SQL

ما یک مدل به نام dim_customers.sql ایجاد می‌کنیم. این مدل، منبع واحد تعریف (Single Source of Definition) برای مشتری و ویژگی‌های او خواهد بود.

-- models/marts/dim_customers.sql

WITH customer_logins AS (
  SELECT
    user_id,
    MAX(login_timestamp) AS last_login_date
  FROM {{ ref('stg_logins') }}
  GROUP BY 1
),

customer_orders AS (
  SELECT
    user_id,
    COUNT(order_id) AS number_of_orders
  FROM {{ ref('stg_orders') }}
  GROUP BY 1
),

customer_support_tickets AS (
  SELECT
    user_id,
    -- Creates a true/false flag if an open high-priority ticket exists
    MAX(CASE WHEN status = 'Open' AND priority = 'High' THEN 1 ELSE 0 END) = 1 AS has_open_high_priority_ticket
  FROM {{ ref('stg_support_tickets') }}
  GROUP BY 1
)

SELECT
  u.user_id,
  u.full_name,
  u.email,
  cl.last_login_date,
  COALESCE(co.number_of_orders, 0) AS number_of_orders,

  -- === THE SINGLE SOURCE OF DEFINITION FOR 'IS_ACTIVE' ===
  CASE
    WHEN cl.last_login_date >= DATEADD('day', -30, CURRENT_DATE())  -- Rule 1
      AND COALESCE(co.number_of_orders, 0) > 0                     -- Rule 2
      AND NOT COALESCE(cst.has_open_high_priority_ticket, false)   -- Rule 3
    THEN TRUE
    ELSE FALSE
  END AS is_active

FROM {{ ref('stg_users') }} u
LEFT JOIN customer_logins cl ON u.user_id = cl.user_id
LEFT JOIN customer_orders co ON u.user_id = co.user_id
LEFT JOIN customer_support_tickets cst ON u.user_id = cst.user_id

✅ چرا این رویکرد برتر است؟

🟡 ۳. حاکمیت بر تعاریف: از کد تا همکاری

تکنولوژی به تنهایی کافی نیست. این تغییر نیازمند یک چارچوب حاکمیتی است.

🏛️ ایجاد کمیته راهبری متریک‌ها (Metrics Governance Committee)

گروهی متشکل از نمایندگان:

🔄 فرآیند مدیریت تغییر (Change Management Process)

💡 نتیجه: این فرآیند تضمین می‌کند که تغییرات به صورت شفاف، هماهنگ و کنترل‌شده انجام می‌شوند.

🟢 ۴. نتیجه‌گیری: تبدیل منطق به یک دارایی مشترک

پنهان کردن منطق کسب‌وکار در کد اپلیکیشن، مانند نوشتن قوانین اساسی یک کشور در یادداشت‌های شخصی یک فرد است. این کار شکننده، غیرقابل دسترس و خطرناک است.

✅ مزایای استخراج منطق تحلیلی

🎯 پیام نهایی

💡 این رویکرد نه تنها از تناقض در گزارش‌ها جلوگیری می‌کند، بلکه اعتماد به داده‌ها را بازسازی کرده و به تیم‌های مختلف اجازه می‌دهد تا با یک زبان مشترک و بر اساس تعاریف یکسان، برای رشد کسب‌وکار همکاری کنند.

این، گامی اساسی در جهت بلوغ داده‌ای و تصمیم‌گیری واقعاً داده‌محور است.