[best0032001]

วันนี้ผมอยากจะชวนมาแสดงความเห็นว่าชอบ ชอบแบบ rich domain model หรือ anemic domain model มากกว่ากัน

ส่วนตัวผมนั้นยังอ่อนมาก ยังไม่เคย ทำแบบ rich domain model เคยแต่ anemic domain model
และอยากจะลองไปทำแบบ rich domain model บ้าง
ซึ่งผมเองก็สับสนพอสมควรว่า มีข้อดีขอเสียแตกต่างกันอย่างไร

อยากให้เปรียบเทียบตาม KPI นี้ครับ

1 ขั้นตอนในการพัฒนา(อะไรใช้ ใช้เวลาเร็วกว่ากัน)
2 เมื่อต้อง maintenance อะไรง่ายกว่ากัน
3 anemic domain model ไม่มี BLLแล้วจะเรียกได้ว่าเราพัฒนาแบบ OO แล้วได้จริงไหมเพราะเป็น object ที่มีแต่ properties

4 อะไร resuse ง่ายกว่ากัน
5 เมื่อออกแบบ แนว OO(ข้อดีเพื่อ ออกแบบให้งานซับซ้อนได้ง่าย) อะไรดีกว่ากัน

เอาแค่ 5ก่อนนะครับ มากกว่านี้คงพูดกันไม่จบ

This post has been edited by best0032001: 03 March 2009 - 09:33 AM

[cblue]

ผมเป็นสาย rich domain model (RDM) ดังนั้นคาดหวังได้ว่าการตอบจะ bias นะครับ โปรดใช้วิจารณญาณ

1 ขั้นตอนในการพัฒนา
RDM ที่ผมใช้ค่อนข้างทำให้การ implement domain objects กระชับ ในระดับที่ไม่มีอย่างอื่นมาเกี่ยว ยกเว้น business logic

2 เมื่อต้อง maintenance อะไรง่ายกว่ากัน
เมื่อจำนวน line of codes น้อยกว่า การ maintain ย่อมง่ายกว่า
RDM ที่ผมใช้อยู่ ใช้ code น้อยกว่าการเขียนแบบเดียวกันด้วยวิธีการอื่นกว่าครึ่ง

3 ข้ามครับ

4 อะไร resuse ง่ายกว่ากัน
มองการ reuse ในระดับทั่วไป ถ้า encapsulate เป็น component ได้ (เช่น .jar) การ reuse ไม่ต่างกันครับ

5 เมื่อออกแบบ แนว OO(ข้อดีเพื่อ ออกแบบให้งานซับซ้อนได้ง่าย) อะไรดีกว่าักัน
RDM แน่นอนครับ
สิ่งที่จะดีที่สุดในการออกแบบด้วย OO ตามความคิดของผมคือ ทำอย่างไรก็ได้ให้สามารถ model domain ได้โดยไม่ต้องใช้ design pattern มากนักครับ

ปล. ถ้าอยากให้ลองเทียบกันเป็นกรณี ๆ ลองยกมาเป็นโจทย์ แล้วเอา code มาเทียบกันดูก็น่าจะเป็นประโยชน์กับท่านอื่น ๆ ด้วยครับ

[juacompe]

cblue, on Mar 3 2009, 12:55 AM, said:

ผมเป็นสาย rich domain model (RDM) ดังนั้นคาดหวังได้ว่าการตอบจะ bias นะครับ โปรดใช้วิจารณญาณ

1 ขั้นตอนในการพัฒนา
RDM ที่ผมใช้ค่อนข้างทำให้การ implement domain objects กระชับ ในระดับที่ไม่มีอย่างอื่นมาเกี่ยว ยกเว้น business logic

2 เมื่อต้อง maintenance อะไรง่ายกว่ากัน
เมื่อจำนวน line of codes น้อยกว่า การ maintain ย่อมง่ายกว่า
RDM ที่ผมใช้อยู่ ใช้ code น้อยกว่าการเขียนแบบเดียวกันด้วยวิธีการอื่นกว่าครึ่ง

3 ข้ามครับ

4 อะไร resuse ง่ายกว่ากัน
มองการ reuse ในระดับทั่วไป ถ้า encapsulate เป็น component ได้ (เช่น .jar) การ reuse ไม่ต่างกันครับ

5 เมื่อออกแบบ แนว OO(ข้อดีเพื่อ ออกแบบให้งานซับซ้อนได้ง่าย) อะไรดีกว่าักัน
RDM แน่นอนครับ
สิ่งที่จะดีที่สุดในการออกแบบด้วย OO ตามความคิดของผมคือ ทำอย่างไรก็ได้ให้สามารถ model domain ได้โดยไม่ต้องใช้ design pattern มากนักครับ

ปล. ถ้าอยากให้ลองเทียบกันเป็นกรณี ๆ ลองยกมาเป็นโจทย์ แล้วเอา code มาเทียบกันดูก็น่าจะเป็นประโยชน์กับท่านอื่น ๆ ด้วยครับ

+1 ครับ (+ ตั้งแต่ผมเป็นสาย... จนถึง ปล.เลยครับ )

แอบเติมข้อ 3 ให้ครับ ถ้าสงสัยว่า Anemic Domain Model เป็น OO ไหม? แวบแรกที่ผมคิดคือ มันก็เหมือน transaction script นี่นา (แล้วพออ่านใน Wikipedia ก็พบว่าคนที่เขียนในนั้นก็เชื่ออย่างนั้นเหมือนกัน)

Transaction script ก็อยู่ในหนังสือ Patterns of Enterprise Application Architecture ที่ผมเคยแนะนำให้น้อง best ไปอ่านแล้วนะครับ (แต่ผมเดาว่าน้องคงยังไม่มีเวลาไปศึกษา ^ ^") ถ้าเขียน transaction script ด้วย structure แบบใน pattern ละก็ ต้องเป็น OO แน่นอนเพราะมันใช้ inheritance แต่ถ้าไม่เขียนตาม pattern ก็สามารถทำสิ่งที่คล้ายๆกันได้เหมือนกัน

สรุปว่าเป็นไหม? ผมตอบว่าเป็นก็ได้ ไม่เป็นก็ได้ แล้วแต่คนเขียนครับ

[tapeza555]

อึม.. ไม่ค่อยได้เข้ามาขอความรู้นาน เห็นมี หลายกระทู้ น่าสนใจ
ขอบคุณ คุณเบส จริงๆๆ(อายุเท่ากัน แต่เก่งกว่าผมเยอะเลย T_T) ที่ตั้งกระทู้แบบนี้ ชอบๆๆ
ผมเองก็อยากรู้เหมือนกันครับ ว่า จะทำยังไงดี
ผมเองก็ทำทางฝั่ง .NET ซึ่ง ถ้าเป็น Microsoft
ก็เจอแต่ ตัวอย่าง ที่เป็น anemic domain model (น่าจะใช่มั้ง)
เช่น มี BE (Business Entity : เก็บ Data ) ,BC(Business Coponent : จัดการ Logic)
แต่ใจจริงคือ อยากจะทำที่เป็น Rich Domain Model เหมือนกัน
ผมคงต้องศึกษาจากพวกพี่ๆ อีกเยอะเลย ขอความรู้ด้วยครับ

This post has been edited by tapeza555: 03 March 2009 - 03:49 PM

[juacompe]

ถ้าผมเข้าใจไม่ผิด Rich/Anemic Domain Model อยู่ใน business logic layer หากแต่คำถามของคุณ tapeza555 กางครอบตั้งแต่ presentation layer จนถึง persistence layer เลยครับ ^ ^"

เนื่องจากตอนนี้ทำงานไม่ทัน เลยขออนุญาตแนะนำแค่ว่า ทุกๆคำถามของคุณ tapeza555 เราเคยถกกันมาแล้วในกระทู้เก่าๆครับ ถ้าคุณ tapeza555 อยากได้คำตอบอันรวดเร็ว รบกวนค้นกระทู้เก่าแล้วลองอ่านดูนะครับ และถ้าสงสัยอะไรก็ถามเรื่องนั้นๆในกระทู้ดังกล่าวต่อเลย

ถ้าค้นไม่เจอ อดใจรอซักนิด ไว้ผมว่างแล้วจะเอา links ที่เหมาะสมมาแปะไว้ให้ครับ

ปล.
- ที่ไม่ตอบต่อในนี้เพราะ 1. ยังไม่ว่างจริงๆ 2. กลัวกระแสกระทู้จะเบี่ยงเบนไปแล้วน้อง best จะไม่ได้คำตอบที่คาดหวังครับ >.<
- ใครที่เคยผ่านตากระทู้เหล่านี้มาก่อน รบกวนเอา links มาแปะให้ทีครับ

[tapeza555]

ขอบคุณ juacompe ครับมากๆ
ผมก็ติดตามกระทู้ เหล่านี้มาพอสมควรครับ
แต่พอดีอ่านไป อ่านมา ยังจับประเด็นไม่ค่อย ได้ครับ
เดี๋ยวผมจะไป Edit โพสต์ จะได้ไม่ผิดประเด็น ดีกว่า

[Rux]

การออกแบบ Software โดยแยก code เป็น layer ผมเคยทำแต่ที่เป็น anemic domain model อย่างเดียว ยอมรับว่านึกภาพไม่ออกว่าแบบ rich มันจะเป็นยังไง

แต่อย่าแรกที่สงสัยเลย คือ อย่างนี้เราจะต้องโยน rich domain model ของเราข้ามไปข้ามมาระหว่าง layer ต่างๆ เหรอครับ อาจจะไป Presentation บ้าง มา Data Access บ้าง

ถ้าถามว่าแบบนี้มันไม่ดีตรงไหน ผมก็ยังบอกไม่ได้ครับว่า object แบบที่มี attribute อย่างเดียว พอโยนข้าม layer มันดีกว่าหรือแย่กว่า แบบพ่วง method ที่เป็น logic ไปด้วยยังไง

สงสัยต้องลองทำสักทีซะแล้ว

[best0032001]

Quote

Transaction script ก็อยู่ในหนังสือ Patterns of Enterprise Application Architecture ที่ผมเคยแนะนำให้น้อง best ไปอ่านแล้วนะครับ (แต่ผมเดาว่าน้องคงยังไม่มีเวลาไปศึกษา ^ ^")

หนังสือ เล่มนี้ ผมต้องหาอ่านให้ได้ครับเห็นหลายท่านแนะนำเหลือเกิน
ทั้ง พี่ข้าวโพดหวาน ด้วย

Quote

ถ้าถามว่าแบบนี้มันไม่ดีตรงไหน ผมก็ยังบอกไม่ได้ครับว่า object แบบที่มี attribute อย่างเดียว พอโยนข้าม layer มันดีกว่าหรือแย่กว่า แบบพ่วง method ที่เป็น logic ไปด้วยยังไง

ส่วนของคุณRux เดียวผมขอไปต่อที่อีกกระทู้นะครับ คงลงเทคนิค.netกัน

ผมไม่เคยทำแต่อ่านและศึกษามาแล้ว รู้ว่าจะทำไง ถึงจะเป็น rich domain model

ซึ่งที่ผมขาดอย่างเดียว คือตัวอย่าง ที่ใช้ LINQ และเป็น rich domain modelเนียไปเจอ คงต่อไปอีกกระทู้

ส่วนที่ผมสนใจมากที่สุดคือ

Quote

1 ขั้นตอนในการพัฒนา
RDM ที่ผมใช้ค่อนข้างทำให้การ implement domain objects กระชับ ในระดับที่ไม่มีอย่างอื่นมาเกี่ยว ยกเว้น business logic

2 เมื่อต้อง maintenance อะไรง่ายกว่ากัน
เมื่อจำนวน line of codes น้อยกว่า การ maintain ย่อมง่ายกว่า
RDM ที่ผมใช้อยู่ ใช้ code น้อยกว่าการเขียนแบบเดียวกันด้วยวิธีการอื่นกว่าครึ่ง

นี้เลยครับ น่าสนใจมาก ทำไม RDM ถึง codeน้อยกว่า ผมยังคิดไม่ออก
(ตัวอย่าง JAVA ก็ได้เลยนะครับคุณ cblue)

ผมชอบทั้ง 2อย่าง(JAVA .NET)

This post has been edited by best0032001: 03 March 2009 - 07:17 PM

[cblue]

เพื่อเพิ่มความ bias ไปอีกนิดหน่อย
ลองเล่นตัวนี้ดูก็ได้ครับ

แต่เนื่องจากเริ่มเกี่ยวข้องกับการ implement
ผมแปะสีดำไว้เพื่อลดความ bias ที่เพิ่มขึ้นครับ

Spoiler

petclinic-mvc
วิธีการลองคือ ไป svn co ออกมา
- ในเครื่องต้องมี ant และ set ANT_HOME ไว้แล้ว
- ใน build.xml แก้บรรทัดที่ 60 ที่มี fileset 2 tag ให้เหลือแค่ <fileset dir="lib" />
- แล้วก็ ant war จากนั้นก็เดินไปหาอะไรกินซักพัก (เพราะมีการใช้ ivy ไป resolve .jar มาจำนวนหนึ่งครับ)
- ถ้า net เร็วกลับมาก็จะได้ .war ไปทดลอง อยู่ที่ target/petclinic.war (ผมลอง deploy ลง tomcat 6.0.18)

สำหรับ class ของ domain object อยู่ใน directory นี้ครับ

ผมคิดว่าสำหรับท่านที่คุ้นเคยกับ model แบบ classic ของตัวอย่างที่ให้ดู น่าจะเห็นแล้วเปรียบเทียบได้ระดับนึงเลยโดยไม่ต้องใช้เวลามากนัก

[minimalist]

ถ้าผมทำงานให้คนอื่นจะใช้ Anemic Domain Model
แต่ถ้าผมทำงานของตัวเองจะใช้ Rich Domain Model

Anemic Domain Model ผมว่าเหมาะกับงานด้าน Enterprise ที่ต้องแยก concern ให้ละเอียดและชัดเจน ซึ่งจะทำให้มีระดับ Polymorphism ที่สูง แน่นอนย่อมแลกมาด้วยการแบ่งทีมที่ง่าย..(หรือเปล่า?) แบ่งทีมแบบ horizontal structure ซึ่งเหมาะกับทีมใหญ่ ๆ หลาย ๆ คน แบ่งหน้าที่กันชัดเจน, maintain ง่าย, มี loose coupling น้อย ฯลฯ แต่ Anemic Domain Model อาจทำให้เกิดเลเยอร์เพิ่มขึ้น ซึ่งก็มีทั้งข้อดีและเสีย

เท่าที่พบมาหลายคนอยากใช้แนว Anemic Domain Model โดยออกแบบให้เรียบง่าย ไม่ให้ซับซ้อนนัก แต่พบว่าการออกแบบให้ดีจำเป็นต้องมีพื้นฐานด้านการออกแบบ transaction ที่แข็งปึ้ก แต่พบว่าส่วนมากมักพลาดตรงจุดนี้ คืออาจแบ่งเลเยอร์กันได้ดี แต่พอมาถึงจุด transaction มักออกแบบและจัดวางส่วน procedure และ business logic กันไม่ถูกหรือไม่เป็นระเบียบ ทำให้เกิดการ call ขึ้น ๆ ลง ๆ ระหว่างเลเยอร์ จน reuse ยาก แทนที่ควรจะ reuse ได้มาก ๆ

Rich Domain Model ผมว่าเหมาะกับทีมแบบ vertical structure ซึ่งแน่นอนเหมาะกับแนวการทำงานแบบ Agile และ Model Driven Development (ยิ่งออกแบบเองเขียนโค้ดเองยิ่งสะดวก) เพราะการได้ใส่รายละเอียดใน domain model เต็มที่ มันก็เหมือนการนำ design pattern ใส่เข้าไปกลาย ๆ ตั้งแต่ต้น ๆ ในระดับ domain model เลย คล้ายกับว่าตอนออกแบบ domain model คนออกแบบก็ต้องออกแบบลงรายละเอียดโดยต้องคำนึงถึง architecture และมองเห็นมิติเชิงลึกและกว้างของงานต่อไป ทำให้พอถึงช่วงอิมพลีเม้นต์ย่อมทำให้โค้ดน้อยกว่าชัวร์ แต่ถ้าผู้ออกแบบออกแบบไม่แม่น พลาดตั้งแต่ domain model ก็จะทำให้เกิดปัญหา ripple effect ตามมาเป็นกระบุงต่อไป

จริง ๆ ผมก็ bias ไปทาง RDM นิด ๆ นะ คล้ายคุณ cblue

[juacompe]

จะมาไล่ค้นกระทู้เก่าว่าต้องดูเรื่องอะไรบ้าง post ของคุณ tapeza555 ดันหายไปซะแล้ว T-T

คุณ minimalist ตอบได้จริงมากครับ เห็นด้วยมากๆเรื่องการแบ่งงานเป็น layerๆ (horizontal) กับแบ่งเป็น moduleๆ (vertical)

ที่ค้นๆมา เจอกระทู้เหล่านี้น่าอ่านครับ
- อันนี้เกี่ยวกับ domain และการเคลือบ business logic Domain class, ขอคำแนะนำค่ะ
- อันนี้เกี่ยวกับ presentation layer ล้วนๆ Enterprise Web Application Framework & Patterns (ดูจากรูป 1 นะครับ)
- อันนี้ตอบคำถามเรื่อง DTO ครับ 3 tier Design
- สุดท้าย, อันนี้อ่านยาก แต่ก็น่าอ่านครับ เต็มไปด้วยความรู้และอารมณ์ ท่านพัฒนา J2EE โดยใช้ Architecture แบบใด?

[นายข้าวโพดหวาน]

เห็นคนอื่นตอบไปเยอะแล้ว ขอเสริมตรงที่ ผมคิดว่าเฟรมเวิร์คที่ใช้มีผลต่อการออกแบบโดเมนโมเดลไม่น้อยทีเดียว อย่างเช่น JEE มีการแบ่ง service layer, DTO, DAO ทำให้ business entities กลายเป็น anemic ไปโดยปริยาย แม้จะออกแบบระบบเป็น rich domain model ก็ต้องสร้าง layer บางๆเพื่อให้เข้ากับเฟรมเวิร์คที่ใช้

ในขณะที่ rich domain model จะไม่เห็นคลาส service เพราะ service สามารถมองเป็น external interface ของโดเมนออบเจ็คอยู่แล้ว ไม่ต้องแยก service object ออกมาต่างหาก การแยก service (รวมถึงการ validate การสร้าง transaction คลุม unit of work และอื่นๆ) ออกจากโดเมนออบเจ็ค อาจเกิดผลเสียตรงที่ business logic กับโดเมนออบเจ็คอยู่คนละที่ ทำให้ต้อง maintain สองฝั่งนี้ดีๆ

[parasit]

1 ขั้นตอนในการพัฒนา(อะไรใช้ ใช้เวลาเร็วกว่ากัน)
anemic เพราะว่าคนส่วนใหญ่ชินกับ procedure style เปลี่ยนมาใช้แบบ anemic เข้าใจง่ายกว่ามาก

2 เมื่อต้อง maintenance อะไรง่ายกว่ากัน
ตามทฤษฎีต้องเป็น rich ง่ายกว่านะครับ เพราะว่า logic กับ state อยู่ที่เดียวกันดูง่าย
แต่ผมคิดว่าคนดี design ต้องแม่นทั้ง OO และ Business มากๆเลยนะถึงจะไม่ออกทะเล

3 anemic domain model ไม่มี BLLแล้วจะเรียกได้ว่าเราพัฒนาแบบ OO แล้วได้จริงไหมเพราะเป็น object ที่มีแต่ properties
เหมือนข้อ 5

4 อะไร resuse ง่ายกว่ากัน
rich ครับ

5 เมื่อออกแบบ แนว OO(ข้อดีเพื่อ ออกแบบให้งานซับซ้อนได้ง่าย) อะไรดีกว่ากัน
ผมมองว่า anemic เหมือนบังคับให้เราเขียนในรูปแบบ transaction script นะครับ

คุณ fowler มองว่า anemic เป็น anti-pattern เลยนะครับ ผมยังไม่บรรลุถึงขั้นนั้นจะอธิบายก็กลัวผิด
แต่คนส่วนใหญ่ก็ยังใช้ anemic อยู่ดี

Quote

สุดท้าย, อันนี้อ่านยาก แต่ก็น่าอ่านครับ เต็มไปด้วยความรู้และอารมณ์ ท่านพัฒนา J2EE โดยใช้ Architecture แบบใด?

กระทู้ classic

[cblue]

Quote

Anemic Domain Model ผมว่าเหมาะกับงานด้าน Enterprise ...
Rich Domain Model ผมว่าเหมาะกับทีมแบบ vertical structure ...

คิดว่าเห็นด้วยครับ ข้อน่าสนใจคือ ทำอย่างไรให้ RDM เหมาะกับทีมแบบ horizontal

Quote

ผมคิดว่าเฟรมเวิร์คที่ใช้มีผลต่อการออกแบบโดเมนโมเดลไม่น้อยทีเดียว

เห็นด้วยเช่นกัน ส่วนตัวคิดว่ามากเลยครับ ทั้งเฟรมเวิร์คและตัวภาษา

[Bleak]

เห็นด้วยเต็มๆกับคุณข้าวโพดหวานเรื่องเฟรมเวิร์ค มันทำให้ design กับ implement กลายเป็นคนละเรื่องเดียวกันได้จริงๆ

1 ขั้นตอนในการพัฒนา(อะไรใช้ ใช้เวลาเร็วกว่ากัน)
ขึ้นอยู่กับทักษะของผู้พัฒนาครับ (คุณ cblue ทำ RDM เร็วกว่า แต่คุณ parasit คง anemic เร็วกว่า)

2 เมื่อต้อง maintenance อะไรง่ายกว่ากัน
สำหรับผมต้อง RDM ครับ แล้วเชื่อไม๊ครับ คนที่มารับช่วงต่อกลับเข้าใจง่ายกว่าแบบ anemic อีก
อาจจะเพราะเค้าจินตนาการได้ถึง real world มั้งครับ

3 anemic domain model ไม่มี BLLแล้วจะเรียกได้ว่าเราพัฒนาแบบ OO แล้วได้จริงไหมเพราะเป็น object ที่มีแต่ properties
อย่างที่คุณ jua บอก มันคือ transaction script หรือจะเป็น command pattern ก็ตามแต่
ถึงแม้มันจะใช้ inheritance ทำให้โครงสร้างดูเป็น OO แต่ผมคิดว่า Meaning ของมันเปลี่ยนไป เหมือนกับเราเอา inheritance มาใช้งานผิดประเภท
สรุปความเห็นผมคือ พัฒนาโครงสร้างแบบ OO แต่ Logic ดูจะเพี้ยนไปนิดๆ

4 อะไร resuse ง่ายกว่ากัน
อย่างที่คุณ cblue ยอก ถ้า encapsulate เป็น component ได้ก็ reuse ไม่ต่างกัน
แต่ถ้าจะเอา reuse ระดับ sourcecode คิดว่า RDM ง่ายกว่าอย่างขัดเจนครับ

5 เมื่อออกแบบ แนว OO(ข้อดีเพื่อ ออกแบบให้งานซับซ้อนได้ง่าย) อะไรดีกว่ากัน
RDM สิครับ ตามข้อ 3 ที่บอกไปคือ ผมรู้สึกว่า anemic ทำให้ OO เพี้ยนไป