Dalam post sebelum ini kami ada:
Jadi, beberapa keputusan diuruskan. Kami mempunyai beberapa alatan dan telah memutuskan rupa repositori itu.
Ini adalah salah satu perkara yang saya suka tentang Polylith: tidak kira apa yang anda pengekodkan atau seberapa besar organisasi anda, semua repositori akan kelihatan sama - jika anda memerlukan lebih daripada satu.
Struktur repositori anda adalah konsisten, sama ada anda menggunakan FastAPI, Flask atau Django, membina perpustakaan tunggal atau berbilang, atau menjalankan tugas latar belakang dengan Celery.
Salah satu kelebihan utama ialah proses onboarding yang diperkemas untuk pembangun baharu. Dengan mengandaikan bahawa mereka memahami Polylith, mereka akan cepat mengenali struktur projek: komponen boleh guna semula berada dalam folder komponen, titik masuk berada dalam folder asas, skrip demo berada dalam folder pembangunan dan sebagainya.
Daripada Uncle Bob "The Clean Architecture" entiti adalah asas seni bina kami, mereka adalah lapisan paling dalam seni bina kami. Jadi kita perlu bermula dengan mereka, dalam Polylith entiti harus hidup sebagai komponen.
Berapa banyak komponen?
Saya percaya bilangan komponen bergantung pada saiz dan kerumitan penyelesaian anda. Walau bagaimanapun, saya mengesyorkan bermula dengan komponen polylith tunggal untuk entiti. Pendekatan ini membantu mengekalkan seni bina yang jelas dan fokus, terutamanya untuk projek yang lebih kecil.
Mengapa satu komponen untuk entiti?
Elakkan kebergantungan pihak ketiga.
Untuk meminimumkan kebergantungan luaran dan meningkatkan fleksibiliti seni bina, berusaha untuk menggunakan perpustakaan standard Python untuk mewakili entiti. Ini termasuk memanfaatkan struktur data seperti dict, senarai, enum, fungsi, kelas dan kelas data yang lebih baru.
Mengapa mengelakkan perpustakaan pihak ketiga seperti Model Pydantic atau Django?
Dengan mematuhi prinsip ini, anda boleh mencipta seni bina yang teguh dan boleh diselenggara yang berdaya tahan terhadap perubahan masa hadapan.
Contoh kami adalah mudah, dengan entiti teras menjadi "item todo" untuk Gordon. Kami boleh menambah komponen baharu pada repositori kami, tetapi memilih nama yang betul adalah penting.
Walaupun mungkin menggoda untuk menggunakan nama generik seperti "teras" atau "utama," adalah penting untuk memilih nama yang bermakna dalam konteks domain. Sebaik-baiknya, nama ini harus sejajar dengan istilah yang digunakan oleh pelanggan atau pemilik produk. Dengan menggunakan nama khusus domain, kami meningkatkan kebolehbacaan dan kebolehselenggaraan kod, menjadikannya lebih mudah bagi pembangun dan pihak berkepentingan untuk memahami struktur projek.
Nama ruang kerja repositori ditakrifkan sebagai todo. Akibatnya, semua import kami akan mengikut format:
from todo.XYZ import ... import todo.XYZ
Untuk kesederhanaan dalam contoh ini, kami akan menggunakan entiti sebagai nama komponen. Walau bagaimanapun, dalam senario dunia sebenar, pertimbangkan konvensyen penamaan yang mencerminkan domain anda. Sebagai contoh, jika aplikasi anda berkisar pada pemulihan dokumen, komponen bernama pemulihan akan sesuai. Begitu juga, aplikasi permainan mungkin menggunakan tournaments_entities untuk kejelasan.
Membuat komponen dengan Python Polylith adalah mudah:
poetry poly create component --name=entities poetry poly sync poetry install # it may be necessary
Ini akan menambah pakej python dalam folder komponen, ini adalah entri baharu dalam pepohon sumber:
./components └── todo └── entities ├── __init__.py └── core.py ./test/components └── todo └── entities ├── __init__.py └── test_core.py
Alat python-polylith akan menjana contoh ujian untuk kami, yang merupakan ciri yang bagus. Tingkah laku ini boleh ditukar dalam fail workspace.toml dengan menetapkan nilai enabled = true kepada false dalam bahagian [tool.polylith.test].
Dalam komponen entiti baharu, dua fail ditambah: __init__.py dan core.py. Anda boleh menamakan semula modul core.py agar lebih sesuai dengan keperluan anda. Amalan biasa adalah untuk mendedahkan API awam pakej melalui __init__.py, sambil mengekalkan organisasi dalaman dalam modul lain seperti core.py.
Daripada keperluan, kami mempunyai, pada masa ini, hanya satu entiti, item Tugasan:
@dataclass class TodoItem: owner: str title: str description: str is_done: bool = False due_date: Optional[date] = None
Menguji entiti semudah itu mungkin kelihatan tidak perlu, tetapi saya lebih suka menguji sekurang-kurangnya kehadiran semua medan. Walaupun ini mungkin kelihatan tidak penting dalam projek yang lebih kecil dengan penyumbang yang lebih sedikit, ia boleh menghalang isu penting dalam projek yang lebih besar dengan banyak pembangun. Mengalih keluar satu medan daripada entiti boleh memecahkan pelbagai bahagian aplikasi secara tidak sengaja.
Dalam permintaan tarik untuk bahagian ini, anda akan melihat bahawa saya telah menambah beberapa ujian asas untuk entiti ini.
Dengan beberapa ujian yang telah ditentukan, saya mengambil peluang untuk menambah aliran kerja GitHub untuk menjalankan ujian secara automatik bagi setiap permintaan tarik.
Apa yang seterusnya: Mari kita bincangkan tentang kegigihan
Atas ialah kandungan terperinci Seni bina bersih: Di mana untuk bermula?. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!