Home > Domain Driven Design > Service (Part 1) Basic

Service (Part 1) Basic

Ketika kita menganalisa domain dan akan mendefinisikan object nya ada sebagian unsur2 yg tidak gampang untuk dibuat padanan objectnya. Object memiliki attribute (internal state) dan memiliki behaviour. Konsep2 yg muncul di UL dipetakan ke dalam code dan noun2 yg muncul dimap ke Object. Dan verb merupakan behaviour dan diletakkan sebagai operasi dari Object yg sesuai. Nah kadang ada operasi yg sulit dicari dimana rumahnya. Maksudnya object tempat dia tinggal. Operasi ini menggambarkan aksi di domain. Jika operasi ini dipaksakan pada suatu object, jadi menyalahin aturan responsibility.

Nah jadi kita harus membuat object tersendiri untuk operasi ini. Kan tidak ada operasi yg berdiri tanpa object. Operasi ini biasanya melibatkan beberapa object. Contohnya Transfer. Memindahkan uang dari satu account ke account yg lain. Coba kita liat. Apakah method transfer bisa kita letakkan di Account. Mmm. Diletakkan dimana. Account yg mentransfer atau account yg ditransfer. Nah jelaslah bahwa itu bukan tanggung jawab dari account.

Jadi kita membuatnya sebagai Service. TransferService contohnya. Service tidak memiliki internal state. Tapi bukan berarti tidak punya instance variable loh. Fungsinya hanya untuk menyediakan fungsionalitas. Dengan membuat service kita dapat membuat konsep di domain (UL) menjadi lebih explicit.

Service biasanya juga menjadi sarana untuk object saling berkomunikasi. Sebagai wadah. Jadi dia bertindak sebagai coordinator antar object. Jika kita memaksakan untuk meletakkan operasi tersebut pada salah satu object. Maka coupling akan terjadi dan code menjadi sulit dimengerti dan diubah.

Kapan kita membuat service ? Ketika operasi itu tidak menemukan tempat tinggal yg cocok di salah satu object. Trus apalagi ? Ketika operasi itu merupakan konsep yg penting di dalam domain. Jadi dia harus explicit.

Karakteristiknya adalah :

1. Operasi yg dilakukan oleh service merupakan concept di domain yg bukan kepunyaan dari salah satu Entity atau Value Object
2. Operasi yg dilakukan Service bukan terhadap dirinya sendiri tetapi ke object lain di domain. Jadi sebagai pengatur. Tugasnya nyuruh2 aja. Biasalah coordinator
3. Operasinya stateless. Jadi tidak ada nyimpan state. Sekali panggil. Selesai. Tidak ada diingat untuk panggilan berikutnya.

Service merupakan suatu term yg bisa banyak artinya. Yg dimaksud di sini adaalah Domain Service bukan RemoteService atau Application Service. Service yg dimaksud di sini adalah kepemilikan dari Domain. Bukan dari Infrastructure.

Domain service dan Application Service dibangun diatas domain Entities dan Value Object. Artinya menggunakan entity dan value object untuk melakukan tugasnya. Nah sekarang kita harus memiliki service ini berada pada layer yg mana. Domain atau Application. Bagaimana cara menentukannya ?

Jika fungsionalitas tersebut hanya untuk berhubungan dengan domain. Hanya untuk koordinasi object2 yg ada di domain. Maka letakkanlah pada domain service. Tapi jika sudah berhubungan dengan infrastructure maka letakkanlah di Application service.

Biasanya sih. Domain Service ini merupakan kelas yg memiliki satu method. Dan bisa juga merupakan kumpulan aksi yg overload.

Biasanya juga domain service ini dinstansiasi di IOC container. Karena juga biasanya butuh repository. Ah kebanyakan biasanya. Dasar kebiasaan. Hehehe

  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: