Mixing Models and Exceptions (การผสมผสานโมเดลและข้อยกเว้น)

อย่าง ที่ผมหวังว่าคงชัดเจนมาถึงตอนนี้ ผมไม่ได้ยึดติดตายตัวในแง่ของวิธีที่คุณหาขอบเขตเหล่านี้ ถ้าคุณทำตามแนวทางของ information hiding และเข้าใจความสัมพันธ์ระหว่าง coupling และ cohesion โอกาสก็คือคุณจะหลีกเลี่ยงกับดักที่แย่ที่สุดบางอย่างของกลไกใดก็ตามที่คุณเลือกได้ ผมมองว่าการมุ่งเน้นแนวคิดเหล่านี้จะทำให้คุณ มีแนวโน้ม มากขึ้นที่จะลงเอยด้วยสถาปัตยกรรมแบบมุ่งเน้น domain แต่นั่นก็เป็นเรื่องรอง ความจริงก็คือมักมีเหตุผลที่จะผสมผสานโมเดลต่าง ๆ เข้าด้วยกัน แม้ว่า "domain-oriented" จะเป็นสิ่งที่คุณตัดสินใจเลือกเป็นกลไกหลักในการกำหนดขอบเขต microservice ก็ตาม

กลไกต่าง ๆ ที่เราได้อธิบายมาจนถึงตอนนี้ยังมีความสัมพันธ์ระหว่างกันที่เป็นไปได้มากมายด้วย การเลือกที่แคบเกินไปตรงนี้จะทำให้คุณเดินตามหลักการตายตัวแทนที่จะทำสิ่งที่ถูกต้อง การแบ่งแบบอิงความผันผวนอาจสมเหตุสมผลมากถ้าจุดมุ่งเน้นของคุณคือการปรับปรุงความเร็วในการส่งมอบ แต่ถ้าสิ่งนี้ทำให้คุณดึง service ที่ข้ามขอบเขตองค์กรออกมา ก็คาดหวังได้เลยว่าความเร็วในการเปลี่ยนแปลงของคุณจะแย่ลงเพราะการแย่งชิงในการส่งมอบ

ผมอาจกำหนด service Warehouse ที่ดีขึ้นมาจากความเข้าใจของผมเกี่ยวกับ business domain แต่ถ้าส่วนหนึ่งของระบบนั้นจำเป็นต้อง implement ด้วย C++ และอีกส่วนหนึ่งด้วย Kotlin คุณก็จะต้องแบ่งเพิ่มเติมตามแนวทางเทคนิคเหล่านั้น

ขอบเขต service ที่อิงองค์กรและอิง domain-driven เป็นจุดเริ่มต้นของผมเอง แต่นั่นก็เป็นแค่แนวทางเริ่มต้นของผมเท่านั้น โดยทั่วไปแล้วปัจจัยหลายอย่างที่ผมได้อธิบายไว้ตรงนี้จะเข้ามามีบทบาท และปัจจัยไหนจะมีอิทธิพลต่อการตัดสินใจของคุณเองก็ขึ้นอยู่กับปัญหาที่คุณกำลังพยายามแก้ คุณต้องพิจารณาสถานการณ์เฉพาะของคุณเองเพื่อกำหนดว่าอะไรได้ผลดีที่สุดสำหรับคุณ และหวังว่าผมได้มอบทางเลือกที่แตกต่างกันสักสองสามอย่างให้คุณพิจารณาแล้ว แค่จำไว้ว่าถ้ามีใครบอกว่า "วิธีเดียวที่จะทำสิ่งนี้ได้คือ X!" พวกเขาก็แค่กำลังขายหลักการตายตัวให้คุณเท่านั้น คุณทำได้ดีกว่านั้น

ด้วยทั้งหมดที่กล่าวมา มาเจาะลึกกันต่อในหัวข้อการสร้างโมเดล domain โดยสำรวจ domain-driven design กันในรายละเอียดมากขึ้นอีกนิด