Spectrum
มีครั้งหนึ่งทีมได้ถกเถียงกันถึง standard ในการเขียนโปรแกรม ซึ่งแบ่งเป็น 2 กลุ่ม คือ Rich Domain Model กับ Anemic Domain Model
ฝั่ง Rich Domain Model ก็บอกว่า Rich Domain Model คือ DDD แท้ๆ แม้แต่ Fowler ยังบอกว่า Anemic คือ Anti-Pattern Model ควรจะ represent business model การแยก service ออกไปไม่ต่างจากการกลับไปเขียน procedural programming
ฝั่ง Anemic ก็แย้งว่า Anemic ทำให้ code clean กว่า แยกเป็นส่วนของ model ที่ไว้ถือ state ของ model เท่านั้นและไม่มี business logic เลย กับส่วนของ service ที่เป็น stateless และมีแต่ business logic การใช้ domain model แบบเดิม ทำให้ 2 models ที่ต่างกัน ทำงานกันลำบาก บางทีก็ต้องเพิ่มอีก layer มาจัดการ
การพูดคุยเริ่มดุเดือดราวกับเป็นศาสนา การโต้แย้งใช้เวลานาน แต่มันก็จบลงเมื่อมีคนเสนอทางออกว่าจริงๆ คำตอบมันไม่ได้มีแค่ 0 กับ 1 คำตอบมันอาจจะเป็น Spectrum ที่อาจจะเป็นค่าใดๆ ระหว่าง 0 กับ 1 ก็ได้
ข้อสรุปของวันนั้นคือ มี model กับ service ตามแนวคิดของ Anemic สิ่งที่เพิ่มมาคือ ใน model สามารถมี business logic ได้ แต่เอาไว้เพื่อจัดการ state ของตัวมันเองเท่านั้น การจัดการ 2 models ขึ้นไปต้องทำผ่าน service layer (บางบทความก็มีความเห็นคล้ายๆ กับข้อสรุปนี้ 1, 2)
ข้อสรุปวันนั้นนอกจากเรื่อง domain model ทำให้รู้จักคำว่า Spectrum คือคำตอบอาจจะไม่ได้ขึ้นอยู่กับตัวเลือกที่ถกเถียงกัน แต่อาจจะอยู่ระหว่างตัวเลือกนั้นๆ ก็ได้
มีครั้งหนึ่งมี application ที่มีคนใช้งานหลักหลายล้านคน ฝ่ายการตลาดกำลังถกเถียงกับ Dev ฝ่ายการตลาดต้องการให้มีการ customization ทุกคนต้องเห็นข้อมูลเฉพาะที่ตนเองสนใจเท่านั้น ส่วนฝ่าย Dev ก็บอกว่าทำไม่ได้ ระบบมันมีหลายล้าน user แถมข้อมูลก็เปลี่ยนแปลงตลอด ผลลัพธ์คือระบบจะทำงานช้ามาก และใช้พลังประมวลผลมหาศาล
เช่นเดิม แต่ละฝ่ายก็พยายามยึดจุดยืนของตัวเอง จึงไม่มีข้อสรุปในวันนั้น และหัวหน้าของทั้ง 2 ฝ่ายได้มาปรึกษากับผม ผมก็ตอบไปว่าคำตอบอาจจะไม่ใช่เลือกระหว่าง customize กับไม่ customize ตัวเลือกระหว่างนั้นอาจจะเป็นการ customize ระดับกลุ่ม แทนที่จะเป็นระดับบุคคล ทำไมไม่ลองจัดคนเป็นกลุ่มๆ เช่นอาจจะมีสัก 10 กลุ่ม เช่น ชอบเทคโนโลยี ชอบแฟชั่น เท่านี้ user ในกลุ่มนั้นก็สามารถเห็นข้อมูลที่ตนเองชื่นชอบ และในแง่ของ performance ก็เท่ากับมีข้อมูล 10 ชุด ไม่ใช่หลายล้านชุดตามจำนวนคน
บางครั้ง Spectrum ก็ถูกเอามาใช้ในการวางแผนงาน มี project นึง Product Owner อยากได้ระบบที่ dynamic เวลาที่เพิ่มสินค้า ซึ่งแต่ละสินค้าต้องการข้อมูลไม่เหมือนกัน แต่อยากที่จะ config อย่างเดียว ไม่ต้อง deploy ระบบใหม่ เพื่อที่จะได้ขายเป็น regional solution แน่นอนระบบประเภทนี้ซับซ้อนมากแน่ๆ และการ config ระบบที่ซับซ้อน ก็ไม่ต่างจากการเขียนโปรแกรมเพิ่ม เพียงแต่ย้ายจากภาษาโปรแกรมไปเป็น config
แรกๆ Dev ก็ร้องว่าระบบแบบนี้ไม่มีวันเสร็จแน่ ครั้งนั้นผมจึงเสนอว่าควรแบ่ง project เป็นหลายๆ phase สำหรับ MVP1 อาจจะ dynamic เฉพาะส่วนที่เปลี่ยนแปลงบ่อยๆ เช่น ตารางราคา release ถัดไปก็เพิ่มความ dynamic เข้าไป เช่น media ต่างๆ ส่วนเรื่อง dynamic ในระดับ UI ก็รอศึกษาจาก release แรกๆ แล้วหาทางทำมันขึ้นมา
Spectrum ไม่ใช่เรื่องใหม่ แต่ละคนก็อาจจะนิยามคำนี้ต่างกันออกไป สำหรับผม ผมชอบคำนี้เพราะมันสื่อถึงว่า คำตอบแม้จะดูเหมือนมีตัวเลือก แต่จริงๆ ตัวเลือกมันต่อเนื่องกัน ไม่ใช่มีการแบ่งคำตอบอย่างชัดเจน