هندسة الصراخ هي مفهوم قدمه مطور البرامج الشهير وقائد الفكر روبرت سي مارتن، والذي يشار إليه غالبًا باسم "العم بوب". قد يبدو هذا المصطلح غير تقليدي، لكنه يمثل مبدأ قويا في تصميم البرمجيات، مع التركيز على جعل بنية النظام تعكس الاهتمامات الأساسية وحالات الاستخدام للتطبيق. بعبارات أبسط، يجب أن "تصرخ" بنية برنامجك بقصده وغرضه.

في هذا الدليل الشامل، سنستكشف أساسيات Screaming Architecture، وكيف تتناقض مع هندسة البرامج التقليدية، وأهميتها في التصميم المستند إلى المجال، وكيف يمكنك تنفيذ هذه البنية في مشاريعك. سنغطي أيضًا أمثلة وسيناريوهات عملية حيث يمكن لـ Screaming Architecture تحسين إمكانية قراءة التعليمات البرمجية وقابلية الصيانة وقابلية التوسع على المدى الطويل.

لماذا العمارة "الصراخ"؟

الفكرة وراء Screaming Architecture هي أن البنية الأساسية لقاعدة التعليمات البرمجية الخاصة بك يجب أن تنقل على الفور غرضها التجاري. وهذا يتناقض مع البنى التقليدية، التي قد تؤكد على الأطر الفنية، أو الأدوات، أو غيرها من الاهتمامات الثانوية. في Screaming Architecture، تحظى اهتمامات المجال بالأولوية على تفاصيل التنفيذ.

أوضح العم بوب مارتن هذا من خلال القياس: تخيل المشي إلى مبنى ورؤية هندسته المعمارية. دون الحاجة إلى لافتة، يمكنك غالبًا معرفة ما إذا كانت مكتبة أو مدرسة أو مكتبًا. وينبغي أن ينطبق الشيء نفسه على هندسة البرمجيات. عندما تنظر إلى بنية المجلد وتصميم التطبيق، يجب أن تفهم على الفور الغرض منه. إذا كنت تقوم بإنشاء نظام محاسبي، فيجب أن تصرخ البنية "المحاسبة"، وليس "Django"، أو "Spring Boot"، أو "React".

مشاكل البنية المرتكزة على إطار العمل

في العديد من المشاريع، يلقي التركيز على أطر التكنولوجيا بظلاله على منطق العمل أو المجال. ستجد هياكل الملفات مثل:

controllers/

services/

repositories/

models/

على الرغم من أن هذه الدلائل مفيدة، إلا أنها تصف الأدوار الفنية بدلاً من أن تعكس المشكلة الأساسية التي يحلها البرنامج. على سبيل المثال، تخبرك هذه البنية أن النظام يستخدم MVC (وحدة التحكم في عرض النموذج) ولكنها لا تعطي فكرة عما إذا كان النظام يتعامل مع البيانات المالية أو إدارة المستخدم أو إنشاء المحتوى.

فخ الإطار

يؤدي التركيز المفرط على الأطر إلى قواعد تعليمات برمجية حيث يتم حجب منطق الأعمال بواسطة النموذج الفني. يصبح النظام المبني حول اتفاقيات إطارية مرتبطًا بشكل وثيق بتلك الأطر. إذا كنت ترغب في تغيير أطر العمل أو مجموعات التكنولوجيا، فإن إعادة البناء تصبح جهدًا كبيرًا. تدافع Screaming Architecture عن الحفاظ على منطق المجال الخاص بك نظيفًا ومنفصلًا، بحيث يصبح اختيار إطار العمل بمثابة تفاصيل تنفيذ بدلاً من البنية الأساسية لقاعدة التعليمات البرمجية الخاصة بك.

الهندسة المعمارية الصارخة في التصميم المبني على المجال (DDD)

غالبًا ما يسير التصميم المعتمد على المجال (DDD) والهندسة المعمارية الصارخة جنبًا إلى جنب. DDD هو نهج لتطوير البرمجيات يركز على التعاون بين الخبراء التقنيين وخبراء المجال، ويركز على نمذجة منطق الأعمال الأساسي بطريقة تتوافق بشكل وثيق مع العمليات في العالم الحقيقي.

في Screaming Architecture، يقع نموذج المجال ومنطق الأعمال في مركز التطبيق، وكل شيء آخر - الأطر وقواعد البيانات وواجهة المستخدم والخدمات - يصبح هامشيًا. الفكرة الأساسية هي أن بنية الكود يجب أن تعكس نموذج المجال بدلاً من تفاصيل التنفيذ الفني.

إليك كيفية تنظيم مشروعك بطريقة "توضح" نيته باستخدام المبادئ المستندة إلى المجال:

/src
    /accounting
        Ledger.cs
        Transaction.cs
        Account.cs
        TaxService.cs
    /sales
        Order.cs
        Invoice.cs
        Customer.cs
        DiscountPolicy.cs

في هذا المثال، تعكس أسماء المجلدات بشكل مباشر اهتمامات العمل: المحاسبة والمبيعات. يتم وضع كل فئة خاصة بالمجال، مثل Ledger وTransaction وOrder، ضمن سياق المجال ذي الصلة. يوضح هذا الهيكل على الفور موضوع النظام وأين يناسب كل مكون.

مثال الكود 1: بنية بسيطة تتمحور حول المجال

فكر في تطبيق للتجارة الإلكترونية يتعامل مع الطلبات والمخزون. باستخدام Screaming Architecture، يجب أن تعكس بنية المجلد منطق العمل بدلاً من الأدوار الفنية:

/src
    /orders
        Order.cs
        OrderService.cs
        OrderRepository.cs
    /inventory
        InventoryItem.cs
        InventoryService.cs
        InventoryRepository.cs

إليك مثال التعليمات البرمجية الأساسي من سياق الطلبات:

public class Order
{
    public Guid Id { get; set; }
    public DateTime OrderDate { get; set; }
    public List Items { get; set; }
    public decimal TotalAmount { get; set; }

    public Order(List items)
    {
        Id = Guid.NewGuid();
        OrderDate = DateTime.Now;
        Items = items;
        TotalAmount = CalculateTotal(items);
    }

    private decimal CalculateTotal(List items)
    {
        return items.Sum(item => item.Price * item.Quantity);
    }
}

public class OrderItem
{
    public string ProductName { get; set; }
    public decimal Price { get; set; }
    public int Quantity { get; set; }
}

في هذا الكود، يكون مفهوم المجال (الطلب) في المقدمة والوسط، مع الاحتفاظ بالمنطق الداعم مثل OrderService وOrderRepository في ملفات منفصلة. يعد منطق الأعمال (CalculateTotal) جزءًا من كيان الطلب، وليس مخفيًا في خدمة أو وحدة تحكم.

تجنب التشتيت الفني

تعتبر الأطر والمكتبات ضرورية لتطوير البرمجيات، لكن لا ينبغي لها أن تملي كيفية هيكلة منطق عملك. تدافع Screaming Architecture عن دفع التفاصيل الفنية مثل وحدات تحكم HTTP، وطبقات الثبات، وأطر قواعد البيانات إلى الأطراف.

إليك مثال يتناقض مع الهندسة المعمارية التقليدية والصراخ:

العمارة التقليدية:

/src
    /controllers
        OrderController.cs
    /services
        OrderService.cs
    /repositories
        OrderRepository.cs
    /models
        Order.cs
        OrderItem.cs

على الرغم من أن هذا صحيح من الناحية الفنية، إلا أنه لا يخبرك بغرض النظام. لا تكشف بنية المجلد شيئًا عن المجال. هل هو نظام التجارة الإلكترونية؟ تطبيق مالي؟ من المستحيل معرفة ذلك دون التعمق في الكود.

عمارة الصراخ:

/src
    /orders
        OrderController.cs
        OrderService.cs
        OrderRepository.cs
        Order.cs
        OrderItem.cs
    /inventory
        InventoryController.cs
        InventoryService.cs
        InventoryRepository.cs
        InventoryItem.cs

يوضح هذا الهيكل على الفور أن النظام يتعامل مع الطلبات والمخزون. إذا أضفت المزيد من النطاقات في المستقبل (على سبيل المثال، العملاء والمدفوعات)، فسيكون لها مكان مخصص في البنية.

دور العمارة النظيفة

غالبًا ما تتوافق هندسة الصراخ مع مبادئ الهندسة المعمارية النظيفة الأوسع للعم بوب. تعمل الهندسة المعمارية النظيفة على تعزيز الفصل بين الاهتمامات، مع التركيز على ضمان استقلال قواعد العمل عن أطر العمل وواجهة المستخدم وقواعد البيانات. تأخذ شركة Screaming Architecture هذه الخطوة إلى الأمام من خلال اقتراح أن هيكل المشروع يجب أن يكشف عن منطق العمل الأساسي.

إليك ملخص سريع للهندسة المعمارية النظيفة:

الكيانات: كائنات العمل الأساسية ومنطقها.

حالات الاستخدام: قواعد العمل الخاصة بالتطبيق.

الواجهات: بوابات للأطر والأنظمة الخارجية.

الأطر وبرامج التشغيل: واجهة المستخدم وقواعد البيانات والمكونات الخارجية الأخرى.

في مشروع الهندسة المعمارية النظيفة، تعد مفاهيم المجال مثل الطلب والعميل والفاتورة جزءًا من الطبقة المركزية. تم نقل أطر العمل مثل ASP.NET Core، أو Django، أو Rails إلى الطبقات الخارجية، لتكون بمثابة آليات لتقديم الوظائف الأساسية.

مثال الكود 2: تطبيق الهندسة المعمارية النظيفة في الهندسة المعمارية الصارخة

في بنية الصراخ، يمكنك هيكلة حالات الاستخدام والكيانات بطريقة تعكس مجال الأعمال. دعونا نوسع مثال التجارة الإلكترونية الخاص بنا:

/src
    /orders
        CreateOrderUseCase.cs
        OrderRepository.cs
        Order.cs
        OrderItem.cs
    /inventory
        AddInventoryItemUseCase.cs
        InventoryRepository.cs
        InventoryItem.cs

إليك مثال لحالة الاستخدام لإنشاء طلب:

public class CreateOrderUseCase
{
    private readonly IOrderRepository _orderRepository;
    private readonly IInventoryService _inventoryService;

    public CreateOrderUseCase(IOrderRepository orderRepository, IInventoryService inventoryService)
    {
        _orderRepository = orderRepository;
        _inventoryService = inventoryService;
    }

    public Order Execute(List items)
    {
        // Ensure all items are available in inventory
        foreach (var item in items)
        {
            _inventoryService.CheckInventory(item.ProductName, item.Quantity);
        }

        var order = new Order(items);
        _orderRepository.Save(order);
        return order;
    }
}

في هذا المثال، يعد CreateOrderUseCase جزءًا من منطق المجال ويتفاعل مع OrderRepository وInventoryService لتلبية احتياجات العمل لإنشاء طلب.

فوائد العمارة الصراخ

تحسين إمكانية القراءة: أي شخص يفتح قاعدة التعليمات البرمجية الخاصة بك سوف يفهم على الفور ما يفعله النظام.

فصل الاهتمامات: يظل منطق الأعمال معزولًا عن التفاصيل الفنية، مما يسهل تغيير الأطر أو التقنيات لاحقًا.

قابلية التوسع: مع نمو النظام، تظل بنية النطاق متسقة، مما يسمح بإضافة ميزات ووحدات جديدة بسهولة.

قابلية الصيانة: من الأسهل الحفاظ على منطق المجال عندما يتم فصله بشكل واضح عن التبعيات والأطر الخارجية.

الإطار الحيادي: تسمح هندسة الصراخ لمنطق الأعمال بالبقاء قابلاً للنقل عبر مجموعات تقنية مختلفة، مع تجنب الاقتران الوثيق مع أي إطار عمل معين.

انتقادات العمارة الصراخ

على الرغم من أن Screaming Architecture لها فوائد عديدة، إلا أنها لا تخلو من الانتقادات:

التعقيد الملحوظ: قد يجد المطورون غير المعتادين على التصميم المعتمد على المجال أن فصل منطق المجال عن التفاصيل الفنية غير ضروري أو معقد للغاية بالنسبة للتطبيقات الصغيرة.
2

. النفقات العامة: في المشاريع الصغيرة أو تطبيقات CRUD البسيطة، قد يبدو تنفيذ Screaming Architecture أمرًا مبالغًا فيه.

منحنى التعلم: بالنسبة للفرق التي اعتادت على مناهج الإطار أولاً، يتطلب اعتماد هندسة الصراخ تحولًا في التفكير قد يستغرق وقتًا لاستيعابه.

متى تستخدم هندسة الصراخ

تعتبر هندسة الصراخ مفيدة بشكل خاص في السيناريوهات التالية:

الأنظمة التي تعتمد على المجال: تطبيقات ذات قواعد عمل معقدة ومنطق المجال.

المشاريع طويلة الأجل: من المتوقع أن تتطور الأنظمة بمرور الوقت، حيث تعد قابلية التوسع وقابلية الصيانة أمرًا بالغ الأهمية.

التطوير عبر الأنظمة الأساسية: الأنظمة التي قد تقوم بتبديل الأطر أو الأنظمة الأساسية، مما يجعل الفصل النظيف لمنطق الأعمال أمرًا ضروريًا.

خاتمة

Screaming Architecture أكثر من مجرد اسم جذاب؛ إنها فلسفة تدعو إلى جعل منطق العمل الأساسي هو الجزء الأبرز في قاعدة التعليمات البرمجية الخاصة بك. من خلال التركيز على مفاهيم المجال بدلاً من الأطر التقنية، يمكن للمطورين بناء أنظمة أكثر قابلية للقراءة والصيانة والتوسع على المدى الطويل. سواء كنت تعمل على تطبيق ويب بسيط أو نظام مؤسسي معقد، فإن اعتماد Screaming Architecture يمكن أن يؤدي إلى تعليمات برمجية أكثر وضوحًا وتركيزًا تعبر عن غرضها بوضوح.

لمعرفة المزيد عن Screaming Architecture، يمكنك الاطلاع على بعض المراجع والقراءات الإضافية:

الهندسة المعمارية النظيفة لروبرت سي مارتن

تصميم يحركه المجال بواسطة إريك إيفانز

مدونة العم بوب على الكود النظيف

من خلال تبني مبادئ Screaming Architecture، يمكنك إنشاء قواعد تعليمات برمجية لا تعمل فحسب، بل "تصرخ" أيضًا بهدفها.