Service (Part 3) Domain Layer dan Application Layer

Term service ini merupakan term yg overload. Domain Service. Application Service, Infrastructure Service. Jadi kita harus bisa menentukan operasi tersebut diletakkan di layer yg mana. Domain service dan Application Service berkolaborasi dengan Infrastructure service.

Contohnya aplikasi bank memiliki fitur mengirimakn email ke nasabahnya jika account balancenya melewati batas yg ditentukan. Nah service dari email atau notifikasi ini merupakan kepemilikan dari infrastructure layer.

Nah sekarang yg kita harus pisahkan adalah domain dan application service. Hal tersebut tergantung dengan domainya. Jika dia mengandung bisnis rule maka letakkan di domain service dan jika tidak letakkan di application service. Tidak boleh ada bisnis logic pada application service.

Advertisement

Service (Part 2) Kesalahan Umum

Kesalahan yg biasa terjadi adalah ketika kita melihat suatu operasi. Kita cenderung mencari pada object apa operasi tersebut cocok diletakkan. Dan kita mungkin saja memaksakannya diletakkan pada salah satu object. Jangan paksakan. Karena jika operasi tersebut merupakan bagian dari UL maka konsep tersebut bisa kabur dan mungkin hilang. Apalagi jika operasi tersebut merupakan konsep yg sangat penting di Domain. Konsep penting harus dibuat seexplicit mungkin. Jadi buatlah kelas untk operasi tersebut.

Jika kita memaksakannya masuk ke dalam satu object. Object tersebut akan kehilangan jati dirinya. Hehehe. Maksudnya udh ga jelas lagi dia bisa apa aja. N mungkin menyalahi SRP. Single Responsibility Principle.

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.

Value Object (Part 2)

Sekedar mengulang saja. Value object tidak memiliki identity. Jadi dia hanya dibandingkan berdasarkan kesamaan nilai saja. contonya untuk membandingkan dua alamat yg sama kita akan membandingkan equality antar komponen2 pembentuk address (street, city, state). Kita lihat contoh berikut.

Kita mungkin akan membuat interface value object seperti ini

public interface ValueObject<t> {

  /**
   * Value objects dibandingkan berdasarkan nilai dari attributenya dan tidak memiliki identity
   *
   * @param other The other value object.
   * @return <code>true</code> if the given value object's and this value object's attributes are the same.
   */
  boolean sameValueAs(T other);
}

Spesification dan Repository

Dengan menggunakan specification pattern kita dapat menulis code sebagai berikut :

IEnumerable<customer> customers = CustomerRepository.AllMatching(CustomerSpecifications.IsGoldCustomer);

Jadi kita dapat mereuse spesifikasi dari domain dan menggunakannya pada repository sebagai metode untuk melakukan query.