육각형 아키텍처의 발견: 강력하고 확장 가능한 코드-PHP 튜토리얼-php.cn

육각형 아키텍처의 발견: 강력하고 확장 가능한 코드

DDD

풀어 주다： 2024-09-13 06:34:12

원래의

721명이 탐색했습니다.

Dalam pembangunan perisian, kami sering berusaha untuk menyelesaikan masalah kebolehskalaan, kebolehselenggaraan dan kebolehujian kod. Di sinilah Seni Bina Heksagon, juga dipanggil "Pelabuhan dan Penyesuai", dimainkan.

Idea pendekatan yang dibangunkan oleh Alistair Cockburn ini ialah domain perniagaan (nadi aplikasi anda) diasingkan daripada seluruh sistem dan boleh digunakan secara bebas daripada teknologi luaran (rangka kerja, pangkalan data, UI, luaran API ).

Ayuh, mari kita mendalami konsep asas Seni Bina Heksagon dan lihat bersama-sama bagaimana ia boleh mengubah cara anda mereka bentuk kod anda! ?

Apakah sebenarnya Seni Bina Heksagon?

Seni Bina Heksagon ialah cara menstrukturkan aplikasi supaya ia bebas daripada butiran luaran. Ia menekankan pengasingan kebimbangan dengan membahagikan aplikasi kepada beberapa lapisan yang berbeza.

Matlamatnya adalah untuk menjadikan aplikasi bebas daripada teknologi tertentu, dengan mengatur interaksi antara nadi aplikasi (logik perniagaan) dan dunia luar (pangkalan data, antara muka pengguna, API, rangka kerja, dll. ), semua ini melalui Pelabuhan dan Penyesuai.

Konsep asas

Bayangkan aplikasi anda sebagai heksagon dengan domain (logik perniagaan) di tengah. Perniagaan teras ini tidak seharusnya dipautkan terus kepada butiran pelaksanaan (seperti Symfony, Doktrin, API pihak ketiga, dsb.). Untuk mencapai matlamat ini, adalah perlu untuk mencipta antara muka yang dipanggil Ports, dan antara muka ini akan dilaksanakan oleh Penyesuai, yang menjaga komunikasi dengan perkhidmatan luaran.

? Pelabuhan: dengan kata lain, antara muka yang melaluinya dunia luar boleh berinteraksi dengan teras perniagaan. Port ialah titik masuk atau keluar aplikasi (API, permintaan HTTP, arahan CLI, dll.).

? Penyesuai: penyesuai ialah pelaksanaan konkrit antara muka ini. Mereka menterjemah permintaan atau respons luaran kepada tindakan yang boleh difahami oleh logik perniagaan. Ini termasuk interaksi dengan pangkalan data, rangka kerja, API, dsb.

Struktur aplikasi heksagon

Untuk memahami dengan lebih baik, kami akan menggunakan contoh mudah dalam Symfony. Mari bayangkan bahawa aplikasi anda mesti membenarkan pengguna membuat pesanan dan ia mesti berinteraksi dengan pangkalan data untuk menyimpan pesanan ini.

Nah, lihat bagaimana anda boleh menstruktur aplikasi anda mengikut seni bina heksagon. ?

1. Jantung Perniagaan

Ini ialah teras aplikasi anda, bahagian yang mempunyai tiada kebergantungan luaran. Di sinilah letak logik perniagaan, seperti membuat pesanan, mengesahkan datanya, dsb.

Découverte de l

Di sini, kelas Pesanan mewakili model asas pesanan. Anda akan perasan bahawa kelas ini tidak tahu apa-apa tentang cara ia akan disimpan atau dari mana data itu datang.

2. Pelabuhan (Antara Muka)

Port mentakrifkan antara muka yang perlu dilaksanakan oleh penyesuai supaya logik perniagaan boleh berfungsi. Ia boleh menjadi titik masuk ke dalam sistem (seperti permintaan HTTP) atau titik keluar (seperti panggilan ke pangkalan data).

Découverte de l

Antara muka OrderRepositoryInterface akan berfungsi sebagai port output. Ia hanya mentakrifkan kaedah yang logik perniagaan perlu berinteraksi dengan pangkalan data. Domain tidak tahu cara data ini akan disimpan.

3. Penyesuai (Pelaksanaan)

Penyesuai ialah pelaksanaan konkrit Port. Penyesuai akan membolehkan anda menterjemah:

semua interaksi luaran terhadap logik perniagaan
logik perniagaan ke arah tindakan konkrit (seperti menyimpan dalam pangkalan data).

Découverte de l

Adapt는 여기서 OrderRepositoryInterface에 대한 호출을 Doctrine(데이터베이스 관리 라이브러리)과의 상호 작용으로 변환하지만 비즈니스 로직에서는 Doctrine이 사용된다는 사실을 전혀 모릅니다.

4. Symfony 컨트롤러의 예

컨트롤러는 애플리케이션의 진입점 역할을 합니다. HTTP 요청을 통해 사용자와 상호작용한 다음 포트 및 어댑터를 통해 도메인에 작업을 위임하는 사람은 바로 그 사람입니다.

Découverte de l

여기서 컨트롤러는 구체적인 구현이 아닌 OrderRepositoryInterface 인터페이스만 알고 있음을 알 수 있습니다. 이를 통해 코드를 테스트 가능하고 확장 가능하며 외부 프레임워크 및 기술(Symfony, Doctrine 등)로부터 독립적으로 만들 수 있습니다.

육각형 아키텍처를 사용하는 이유는 무엇입니까?

비즈니스 로직을 외부 구현(데이터베이스, HTTP, 외부 API)과 분리하면 코드가 더욱 유연해집니다. 데이터베이스나 프레임워크 변경이 더 간단해지고 위험도 줄어듭니다.
비즈니스 로직이 외부 요소에 얽매이지 않으므로 테스트에서 어댑터를 쉽게 모의하거나 교체할 수 있습니다.
이렇게 명확하게 구분하면 비즈니스 로직에 영향을 주지 않고 새로운 기능을 추가하거나 동작을 수정하거나 특정 구성 요소를 재사용하기가 더 쉬워집니다.
다른 유형의 어댑터를 사용하여 동일한 핵심 비즈니스를 재사용할 수 있습니다. 예를 들어 웹 애플리케이션, REST API 또는 명령줄 인터페이스에도 동일한 비즈니스 로직을 사용할 수 있습니다.