Рамката може да направи PHP апликацијата да изгледа завршено многу пред навистина да биде добро дизајнирана. Рутите се разрешуваат, контролерите враќаат JSON, миграциите се извршуваат, а Docker го стартува стекот со една команда. Тоа се корисни придобивки. Но, сами по себе, тие не се архитектура.

Долгорочната одржливост произлегува од избори што остануваат разбирливи кога кодната база расте, барањата се менуваат и првичната имплементација веќе не е свежа во ничија меморија. Рамките треба да ги забрзаат тие избори, а не да ги прикриваат.

Почнете со граници, а не со директориуми

Многу PHP апликации започнуваат со позната структура: контролери, модели, сервиси, репозиториуми, задачи и команди. Ова е разумна почетна точка, но папките не создаваат граници. Контролерот сѐ уште може да содржи правила за цени, ORM моделот сѐ уште може да испраќа е-пошта, а „сервисот“ сѐ уште може да стане нејасно место за собирање неповрзана логика.

Потраен пристап е важниот код да се организира околу деловните способности и зависностите да бидат експлицитни. За систем за нарачки, тоа може да значи концепти како нарачки, каталог, плаќања и испорака. Секоја способност ги поседува своите правила и изложува мал, намерно дизајниран интерфејс кон остатокот од апликацијата.

Практичното прашање е едноставно: ако ново правило го менува начинот на кој се прави нарачка, каде треба да погледне развивачот? Ако одговорот е „неколку контролери, набљудувач, кука на модел и слушател на редица“, границата веќе протекува.

Задржете ги HTTP-грижите на работ

Контролерите треба да го преведуваат HTTP во влез за апликацијата, а излезот од апликацијата во HTTP. Тие треба да ја валидираат формата на барањето, да изберат соодветен статусен код и да го делегираат вистинскиот случај на употреба. Така основниот тек може да се повика од команда, работник во редица или тест без повторно создавање HTTP барање.

final class PlaceOrderController
{
    public function __invoke(PlaceOrderRequest $request, PlaceOrder $useCase): JsonResponse
    {
        $order = $useCase->handle(
            customerId: $request->user()->id,
            items: $request->validated('items')
        );

        return response()->json([
            'id' => $order->id(),
            'status' => $order->status(),
        ], 201);
    }
}

Примерот не бара обемна програма за апстракција. Неговата вредност е во тоа што текот на нарачката има јасно место, додека контролерот останува одговорен за веб-границата.

Користете ја базата на податоци намерно

PHP системите често ја наследуваат својата архитектура од својот ORM. Тоа може да биде продуктивно сѐ додека однесувањето на базата на податоци не стане изненадувачко: имплицитни прашања во циклуси, случајни запишувања при читања, настани на модели со скриени несакани ефекти или трансакции што покриваат само дел од деловна операција.

Третирајте ја базата на податоци како важна зависност со реални ограничувања. Дефинирајте уникатност во базата на податоци кога деловните правила бараат уникатност. Користете странски клучеви таму каде што претставуваат стабилна врска. Додавајте индекси врз основа на вистинските шеми на прашања, а не врз основа на нејасното верување дека „повеќе индекси“ значи побрзи прашања.

На пример, ако API често ги презема неодамнешните нарачки на клиент, релевантното прашање и индексот треба да се разгледуваат заедно. Прашање обликувано околу customer_id, со подредување според времето на создавање, бара стратегија за индексирање соодветна на тој образец на пристап. Точниот индекс зависи од механизмот на базата на податоци и планот на прашањето, затоа проверете го со алатките што ги нуди вашата база на податоци наместо да претпоставувате дека прашањето генерирано од ORM е ефикасно.

Трансакциите нека одговараат на деловното дејство

Трансакцијата не е едноставно одбранбена обвивка околу секое запишување. Таа дефинира атомска единица: или нарачката и нејзините ставки постојат заедно, или не постои ниту едно од нив. Работата во неа нека биде фокусирана и кратка. Мрежни повици, бавни операции со датотеки и надворешни известувања обично не припаѓаат во трансакција на база на податоци.

Кога дејство мора да ажурира локални податоци и подоцна да извести друг систем, прво запишете ја локалната состојба и користете сигурен механизам за предавање на надворешната работа. Суштинскиот принцип на дизајнот е да избегнете тврдење дека надворешниот ефект успеал пред навистина да успее.

Дизајнирајте API како договори

API е ветување кон клиентите, вклучувајќи ги и клиентите што ги одржува вашиот сопствен тим. Чист контролер не помага многу ако API има неконзистентни тела за грешки, недокументирано однесување при пагинација или полиња што го менуваат значењето без најава.

Воспоставете конзистентен договор за одговори при успех и неуспех. Одлучете како се претставуваат грешките при валидација, како се форматираат идентификаторите, што значат метаподатоците за пагинација и дали временските ознаки вклучуваат информации за временска зона. Овие детали го спречуваат нагаѓањето од страна на зависните системи.

• Користете стабилни, значајни имиња на ресурси.
• Валидирајте го влезот на границата, а потоа спроведувајте критични правила и во апликацискиот слој.
• Враќајте грешки со кои клиентите можат програмски да постапуваат, без откривање внатрешни детали од имплементацијата.
• Направете ја идемпотентноста експлицитна грижа за операции што клиентите може да ги повторат.
• Верзионирајте само кога промена на договорот не може да се воведе компатибилно.

Повторните обиди заслужуваат особена грижа. Клиентот може повторно да испрати барање бидејќи не добил одговор, иако серверот ја завршил првичната операција. За крајна точка поврзана со плаќање или создавање нарачка, клуч за идемпотентност зачуван со резултирачката операција може да спречи повторниот обид да создаде дупликат резултат. Имплементацијата мора да дефинира и што се случува кога истиот клуч пристигнува со различен влез: треба да биде одбиен, наместо тивко да се третира како исто барање.

Docker треба да го намалува триењето, а не да го прикрива продукциското опкружување

Docker е вреден кога го прави локалниот развој предвидлив: истите PHP екстензии, верзија на база на податоци, процес на работник и конфигурација на услуги можат доследно да ги стартуваат сите придонесувачи. Станува помалку корисен кога развоен контејнер се третира како доказ дека продукциското распоредување е правилно.

Конфигурацијата нека биде експлицитна. Променливите на околината се корисни за вредности специфични за распоредувањето, но треба рано да се валидираат. Недостасувачки URL на база на податоци или неправилно форматирана поставка за редица треба јасно да откаже при стартување или проверка на здравјето, а не да се појави како збунувачка грешка под оптоварување.

Одделете ги грижите при градење од грижите при извршување. Зависностите треба да се инсталираат репродуцибилно, кодот на апликацијата треба намерно да се пакува, а контејнерите при извршување треба да содржат само што им е потребно за да ѝ служат на апликацијата. Истиот принцип важи и надвор од контејнерите: распоредувањето треба да биде препознатлив артефакт со конфигурација обезбедена од неговата околина.

Перформансите започнуваат со видливост

Работата на перформансите е најефикасна кога започнува со конкретно набљудување: бавна крајна точка, заситен работник, прашање кон база на податоци со скап план или раст на меморијата во долготраен процес. Предвременото кеширање може да замени видлив проблем со латентноста со потежок проблем со конзистентноста.

Мерете го времето на барањата, бројот на прашања кон базата на податоци, неуспесите во редицата и стапките на грешки на начин што му овозможува на развивачот да следи една операција низ системот. Запишувајте доволно контекст за дијагностицирање неуспеси, но избегнувајте внесување акредитиви, токени или непотребни лични податоци во логовите.

Потоа подобрете го најтесното тесно грло. Отстранете N+1 прашање пред да додадете кеш. Пагинирајте неограничени множества резултати пред да ги зголемите ограничувањата за меморија. Преместете навистина бавна, неинтерактивна задача во редица пред HTTP барањето да чека на неа. Секоја промена треба да има јасен очекуван ефект и начин за негова проверка.

Одржливоста е секојдневна дизајнерска практика

Најсилните PHP системи ретко се оние со најмногу обрасци. Тоа се оние во кои развивачот може да проследи барање, да ги разбере правилата, безбедно да промени едно однесување и да го потврди резултатот. Тоа бара читливо именување, фокусирани тестови околу важното однесување, намерни граници и оперативна повратна информација по распоредувањето.

Рамката и понатаму е моќна алатка. Нека се справува со повторливата механика: рутирање, обработка на барања, конфигурација, миграции и точки за интеграција. Но, трајните одлуки нека останат видливи. Кога кодот изразува што прави системот и зошто постојат неговите правила, апликацијата може да ја надживее модата на рамката што помогнала да се изгради.