Archive

Posts Tagged ‘Domain Driven Design’

Service (Part 3) Domain Layer dan Application Layer

February 10, 2009 1 comment

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.
Read more…

Advertisements

Service (Part 2) Kesalahan Umum

February 10, 2009 Leave a comment

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.
Read more…

Service (Part 1) Basic

February 10, 2009 Leave a comment

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.
Read more…

Value Object (Part 2)

February 6, 2009 2 comments

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);
}

Read more…

Spesification dan Repository

February 3, 2009 Leave a comment

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. Read more…

Value Objects

February 3, 2009 Leave a comment

Apakah semua object harus memiliki identity ? Apakah kita akan membuat semua object entity ?

Entity memang mudah ditrack. Karena memiliki identity. Tetapi membuat identity tersebut pun bukan hal yg mudah. Harus dijamin bahwa identity tersebut unique. Semua harus unique. Harus dipikirkan dengan matang. Dan juga bisa gawat klo salah2 menentukan. Dan juga masalah performance muncul jika harus membuat semua object entity. Karena harus dijamin hanya ada boleh satu satu instance untuk tiap object. Read more…

Entities (Part 1)

February 3, 2009 Leave a comment

Ini adalah kategori dari object yg memiliki identitas. Identitas tersebut akan tetap sama selama software berjalan. Jadi bukan nilai dari attribute nya yg penting. Tapi kelansungan hidupnya dan identitasnya.

OOP menyimpan instance dari object di dalam memory. Kita dapat merujuk object tersebut dengan reference ke object tersebut. Reference ini unik untuk setiap object. Tapi kita tidak dapat menjamin bahwa object tersebut akan tetap di sana kan ? Object setiap saat bisa dilepas dari memory atau diciptakan kembali. Nah jadi kita tidak dapat menggunakan reference sebagai identity. Ketika object yg dulu dilepas dari memory dibuat lagi, bagaimana kita dapat mengetahui object tersebut adalah sama ? Dengan identitasnya. Read more…