วิศวกรรมซอฟต์แวร์

ถาม - ตอบสำหรับมืออาชีพนักวิชาการและนักเรียนที่ทำงานในวงจรการพัฒนาระบบ

3
ทีมงานควบคุมคุณภาพควรทำการทดสอบในรูปแบบการแยกสาขาของ Gitflow
เราเป็นทีมใหญ่ (นักพัฒนา 10-12 คนและ 4 คน) ทำงานหลายโครงการด้วยที่เก็บ git เดียวกัน มันเป็นบริการเว็บแบ็กเอนด์ในฤดูใบไม้ผลิตาม เรากำลังมองหาการแยกทางและใช้กลยุทธ์ที่ดี นอกจากนี้เรายังมีทีมงาน qa ที่ทำให้มั่นใจว่าคุณสมบัติของเราทำงานได้ตามที่คาดไว้ (ปราศจากข้อบกพร่องในระดับหนึ่ง) หลังจากอ่านบทความไม่กี่ฉันรู้สึกว่าแบบจำลองGitflowทำงานได้ดีสำหรับเรา ที่นี่คำถามของฉันมา ทีม QA ของเราควรทดสอบคุณสมบัติของเราที่ไหน? พวกเขาควรทดสอบสาขาคุณลักษณะที่พวกเขาจะเพิ่มข้อผิดพลาดและนักพัฒนาจะแก้ไขและเมื่อผ่านการทดสอบ QA เรารวมการพัฒนา และ QA จะทำการทดสอบจำนวนเต็มอีกครั้งในสาขาที่กำลังพัฒนา เราควรรวมคุณสมบัติทั้งหมด (หลังการทดสอบหน่วยและการทดสอบพื้นฐานจากผู้พัฒนา) เพื่อพัฒนาสาขาและให้ทดสอบ qa จากที่นั่น การแก้ไขและการทดสอบทั้งหมดจะเกิดขึ้นในการพัฒนาเช่นกัน ฉันอยากรู้ว่าวิธีการใดที่ทำงานได้ดีสำหรับผู้อื่น
23 testing  git  branching  qa  gitflow 

3
ความแตกต่างระหว่าง API และส่วนหน้า - ส่วนหลัง
ฉันกำลังพยายามเขียนเว็บไซต์ธุรกิจ "มาตรฐาน" โดย "มาตรฐาน" ฉันหมายถึงเว็บไซต์นี้ใช้ HTML5, CSS และ Javascript ปกติสำหรับ front-end, back-end (เพื่อประมวลผลข้อมูล) และรัน MySQL สำหรับฐานข้อมูล มันเป็นเว็บไซต์ CRUD ขั้นพื้นฐาน: Front-end ทำสิ่งที่ฐานข้อมูลมีอยู่ แบ็กเอนด์เขียนไปยังฐานข้อมูลอะไรก็ตามที่ผู้ใช้ป้อนและทำการประมวลผลบางอย่าง เช่นเดียวกับไซต์ส่วนใหญ่ที่ออกมี ในการสร้างที่เก็บ Github ของฉันที่จะเริ่มต้นการเข้ารหัส, ฉันได้ตระหนักถึงฉันไม่เข้าใจความแตกต่างระหว่างfront-end หลังสิ้นสุดและAPI อีกวิธีในการใช้คำถามของฉันคือ: API เข้ามาในรูปภาพนี้ที่ไหน ฉันจะเขียนรายละเอียดเพิ่มเติมจากนั้นคำถามที่ฉันมี - หวังว่านี่จะช่วยให้พวกคุณมีความคิดที่ดีขึ้นว่าคำถามจริงของฉันคืออะไรเพราะฉันสับสนจนฉันไม่รู้คำถามที่จะถาม รายละเอียดเพิ่มเติมบางส่วน: ฉันต้องการลองใช้รูปแบบ Model-View-Controller ฉันไม่รู้ว่านี่เป็นการเปลี่ยนแปลงคำถาม / คำตอบหรือไม่ API จะสงบ ฉันต้องการให้back-end ของฉันใช้ API ของตัวเองแทนการอนุญาตให้ back-end โกงและโทรสอบถามพิเศษ ฉันคิดว่าสไตล์นี้มีความสอดคล้องมากกว่า คำถามของฉัน: …

6
เหตุใดคุณจึงมีคำนิยามวิธีการภายในไฟล์ส่วนหัวใน C ++ เมื่ออยู่ใน C คุณไม่สามารถ?
ใน C คุณไม่สามารถนิยามฟังก์ชัน / การนำไปใช้ภายในไฟล์ส่วนหัว อย่างไรก็ตามใน C ++ คุณสามารถใช้วิธีการเต็มรูปแบบภายในไฟล์ส่วนหัว ทำไมพฤติกรรมต่างกัน
23 c++  c  headers 

5
"สถาปัตยกรรมสะอาด" โดยบ็อบมาร์ตินเป็นกฎง่ายๆสำหรับสถาปัตยกรรมทั้งหมดหรือเป็นเพียงหนึ่งในตัวเลือกหรือไม่?
ผมชอบแนวคิดในวิดีโอหลักการสะอาดสถาปัตยกรรมโดยลุงบ๊อบมาร์ติน แต่ฉันรู้สึกว่ารูปแบบนี้เหมือนกับการรวมกันของรูปแบบนามธรรมจากโรงงานและตัวสร้างที่แกนกลางของมัน นี่เป็นวิธีหนึ่งในการเขียนโปรแกรมที่ดี แต่ไม่ใช่วิธีเดียว Rails และ reactjs เป็น 2 เฟรมเวิร์กที่มาพร้อมกับจิตใจที่ไม่สนับสนุนสถาปัตยกรรมที่สะอาดเช่นนี้ Rails คาดว่าตรรกะทางธุรกิจของคุณจะอยู่ในรูปแบบ ( FatModels และ SkinnyControllers ) และตอบสนองภายในองค์ประกอบของคุณ ทั้งสองวิธีทั้งคู่แน่นตรรกะทางธุรกิจและรหัสกรอบ ฉันไม่พบสิ่งผิดปกติใน 3 วิธี มันเป็นการตัดสินใจที่จะเลือกใคร แต่ในวิดีโอฉันรู้สึกว่าเขาแนะนำว่าสถาปัตยกรรมสะอาดควรมีขอบเขตที่ชัดเจนระหว่างตรรกะทางธุรกิจและกรอบงาน Frameworks (เว็บแอนดรอยด์ ฯลฯ ) ควรเป็นปลั๊กอินที่เชื่อมต่อกับตรรกะทางธุรกิจ เขายังแยกรางรถไฟในวิดีโออย่างละเอียด ดังนั้น"Clean Architecture" โดย Bob Martin เป็นกฎง่ายๆสำหรับสถาปัตยกรรมทั้งหมดหรือเป็นเพียงหนึ่งในตัวเลือกหรือไม่

19
การใช้ซอฟต์แวร์ละเมิดลิขสิทธิ์ / แคร็กเพื่อการพัฒนา [ปิด]
ตามที่เป็นอยู่ในปัจจุบันคำถามนี้ไม่เหมาะสำหรับรูปแบบคำถาม & คำตอบของเรา เราคาดหวังคำตอบที่จะได้รับการสนับสนุนจากข้อเท็จจริงการอ้างอิงหรือความเชี่ยวชาญ แต่คำถามนี้อาจเรียกร้องให้มีการถกเถียงอภิปรายโต้แย้งหรือการอภิปรายเพิ่มเติม หากคุณรู้สึกว่าคำถามนี้สามารถปรับปรุงและเปิดใหม่ได้โปรดไปที่ศูนย์ช่วยเหลือเพื่อขอคำแนะนำ ปิดให้บริการใน8 ปีที่ผ่านมา ล็อคแล้ว คำถามและคำตอบนี้ถูกล็อคเนื่องจากคำถามอยู่นอกหัวข้อ แต่มีความสำคัญทางประวัติศาสตร์ ขณะนี้ไม่ยอมรับคำตอบหรือการโต้ตอบใหม่ ข้อจำกัดความรับผิดชอบ: ฉันไม่เอาผิดกับการใช้ซอฟต์แวร์ละเมิดลิขสิทธิ์ คุณเคยเห็นการใช้ซอฟต์แวร์ละเมิดลิขสิทธิ์เพื่อจุดประสงค์ในการพัฒนาหรือไม่? อาจเป็น บริษัท ที่มีเงินไม่พอที่จะซื้อซอฟต์แวร์หนึ่งชิ้นและไม่มีทางเลือกฟรี อาจเป็น บริษัท ที่ต้องการทดลองใช้ก่อนที่จะซื้อและไม่มีใบอนุญาตทดลองใช้งานสำหรับผลิตภัณฑ์นั้น คุณเคยทำงานใน บริษัท ที่ยอมรับการใช้ซอฟต์แวร์ละเมิดลิขสิทธิ์หรือแคร็ก มีผลกระทบอะไรบ้างในการทำเช่นนี้?
22 security  ethics 

1
วิธีปฏิบัติที่ดีที่สุดในการจัดการกับ PRs คือการจัดการกับช่องโหว่ความปลอดภัยใน repo สาธารณะ
โครงการโอเพ่นซอร์สที่ควรมีพื้นที่เก็บข้อมูลสาธารณะจัดการกับคำขอดึง (PRs) ที่ดีที่สุดที่อยู่รายงานอย่างปลอดภัย แต่ยังไม่เปิดเผยช่องโหว่ความปลอดภัยสาธารณะ ฉันเกี่ยวข้องกับโครงการโอเพ่นซอร์สที่มีผู้ร่วมให้ข้อมูลหลายร้อยคน เราเผยแพร่ประกาศเกี่ยวกับความปลอดภัยและช่องโหว่หลายครั้งต่อปีโดยเป็นส่วนหนึ่งของการวางจำหน่ายรายเดือนตามกำหนด เราจะไม่เผยแพร่ข้อมูลเกี่ยวกับช่องโหว่จนกว่าเราจะเผยแพร่เวอร์ชันที่ได้รับการแก้ไข เราสามารถจัดการปัญหาด้านความปลอดภัยได้อย่างปลอดภัยในระบบการจัดการโครงการ (JIRA) แต่เราไม่ได้มีกระบวนการที่ดีในการปิดบัง PRs ที่แก้ไขจุดอ่อนด้านความปลอดภัยเมื่อส่งไปยัง GitHub เรากังวลว่าผู้คนสามารถค้นหาการแก้ไขเหล่านี้ได้ก่อนที่จะเผยแพร่และสร้างการหาประโยชน์ที่ไม่มีวันหยุด เราได้พิจารณาการใช้ repos ส่วนตัวที่แยก repo หลัก แต่ส่วนใหญ่ของการตรวจสอบของเราในปัจจุบันและเวิร์กโฟลว์ QA เกิดขึ้นใน PRs ถ้าเราย้ายเวิร์กโฟลว์ไปที่ทีมรักษาความปลอดภัยเฉพาะ repo ส่วนตัวซึ่งจะลดหน้าต่างเมื่อการแก้ไขเป็นแบบสาธารณะลงจนถึงเวลาที่ใช้ในการสร้าง tarball และเผยแพร่บน sourceforge ซึ่งจะเป็นการปรับปรุงครั้งใหญ่ นอกจากนี้เรายังอาจต้องหลีกเลี่ยงการรวม PR เข้ากับเบต้าสาธารณะของเรา ก่อนที่จะไปในทิศทางนั้นฉันต้องการทราบว่าวิธีที่ดีที่สุดในการจัดการแพทช์แก้ไขข้อบกพร่องด้านความปลอดภัยก่อนวางจำหน่ายในโครงการโอเพ่นซอร์สที่มี repos แบบเปิดคืออะไร หากปัญหาสามารถแก้ไขได้ดีขึ้นโดยใช้แพลตฟอร์มอื่นที่ไม่ใช่ GitHub ฉันควรพูดถึงว่าเรากำลังประเมินการโยกย้ายไปยัง GitLab

6
ฉันจะจัดทำรหัสสำหรับการตรวจสอบเวลาน้อยที่สุดได้อย่างไร [ปิด]
ปิด คำถามนี้จะต้องมีมากขึ้นมุ่งเน้น ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้มุ่งเน้นที่ปัญหาเดียวโดยแก้ไขโพสต์นี้ ปิดเมื่อปีที่แล้ว ฉันต้องการเอกสารรหัสของฉันเพื่อให้มีความจำเป็นขั้นต่ำสำหรับการอ่านและเรียกดูรหัสอีกครั้งในภายหลัง ฉันรู้ว่ามีเอกสารประเภทต่าง ๆ (ในซอร์สโค้ดและภายนอก, แผนภาพลำดับและอื่น ๆ ) ฉันแค่อยากจะรู้ว่าอะไรคือวิธีที่มีประสิทธิภาพในการจัดทำรหัสของฉันเพื่อที่เมื่อไม่กี่เดือนต่อมาฉันต้องการเห็นรหัสของฉันฉันใช้เวลาน้อยลงในการอ่านรหัสและการทำความเข้าใจโค้ดที่ลื่นไหล

11
การสร้างคีย์หลักรองในฐานข้อมูลสำหรับบางตาราง
ในบางตารางของฉันฉันต้องการเพิ่ม "second_primary_key" ซึ่งจะเป็น uuid หรือบางคีย์ยาวแบบสุ่ม ฉันต้องการเพราะบางตารางฉันไม่ต้องการให้จำนวนเต็มกับเว็บแอปพลิเคชันของฉัน นั่นคือในหน้า "/ ใบแจ้งหนี้" ฉันมีรายการใบแจ้งหนี้และลิงก์ไปยัง "/ ใบแจ้งหนี้ /: id" โดยที่: id เป็นจำนวนเต็ม ฉันไม่ต้องการให้ผู้ใช้ทราบจำนวนใบแจ้งหนี้ในระบบของฉันที่นั่นดังนั้นแทนที่จะเป็น "/ ใบแจ้งหนี้ / 123" ฉันต้องการใช้ "second_primary_key" เพื่อให้ URL เป็น "/ ใบแจ้งหนี้ / N_8Zk241vNa" เช่นเดียวกันกับตารางอื่น ๆ ที่ฉันต้องการซ่อนรหัสจริง ฉันสงสัยว่านี่เป็นเรื่องธรรมดาหรือไม่ วิธีที่ดีที่สุดในการใช้งานนี้คืออะไร และเทคนิคนี้เรียกว่าอะไรหลังจากทั้งหมดเพื่อที่ฉันจะค้นหามัน?

8
เปรียว - เราทำผิดอะไร
ฉันเป็นผู้พัฒนาทีมเปรียวและเราพยายามใช้การต่อสู้ ดังนั้นฉันจะทำให้ปัญหาสมมุติที่นี่เพื่อแสดงสถานการณ์ เรามีแอพที่เก่าแก่มากโดยใช้โค้ด JQuery ที่บำรุงรักษาไม่ดีและยุ่ง นอกจากนี้เรายังมีส่วนต่าง ๆ ของแอปที่ใช้ React และส่วนเหล่านั้นเป็นวิธีที่ง่ายต่อการอัปเดต / ดูแล นอกจากนั้นเป้าหมายของ บริษัท คือการสร้างลูกค้าแบบหน้าเดียวในแอป React ดังนั้นการใช้ JQuery จะทำให้คุณห่างไกลจากสิ่งนั้น เมื่อเราทำการวางแผนเรามักจะไปหาทางออกที่ง่ายในแง่ของเวลาในการพัฒนาดังนั้นตัวอย่างเช่นถ้าเรากำลังสร้างกล่องโต้ตอบใหม่หรืออะไรเราใช้ JQuery เก่าเพราะมันเร็วกว่าและเราบอกว่าเรากลับไป ต่อมาเป็นระเบียบเรียบร้อยและเปลี่ยนเป็นปฏิกิริยา แต่ก็ไม่ค่อยเกิดขึ้น เราได้รับข้อกำหนดของสิ่งที่เราต้องทำจากเรื่องราวของผู้ใช้ (ซึ่งทำได้ดี IMO พวกเขามีรูปร่างเพรียวบาง แต่พวกเขาอธิบายสิ่งที่เรากำลังทำและทำไมเราถึงทำมัน) บางครั้งข้อกำหนดของฟีเจอร์ใหม่นั้นบางมากตัวอย่างเช่นถ้าข้อกำหนดบอกว่า "ทำไดอะล็อกที่โหลดเนื้อหาจำนวนมาก" แต่ไม่ได้บอกว่าจะใช้คุณสมบัติการโหลดเราส่วนใหญ่จะไม่ใช้มัน ถึงแม้ว่าเราทุกคนรู้ว่ามันจะดีกว่าสำหรับลูกค้าด้วยเหตุผลที่ว่านี้สามารถประนีประนอมเป้าหมายการวิ่งของเรา (แม้ว่าฉันเชื่อโดยส่วนตัวว่ามันจะไม่) ผลที่ได้คือ codebase ของเรายุ่งเหยิงอย่างมากกับการบำรุงรักษาที่แย่มากและบางครั้งคุณสมบัติใหม่ ๆ ก็เล็กมากและวิ่งเต็มรูปแบบเพื่อทำสิ่งที่สามารถทำได้ในหนึ่งวันใน codebase ที่ดีส่วนใหญ่เป็นเพราะการพัฒนานี้ กลยุทธ์เพียงไปอย่างรวดเร็วทำสิ่งเล็กน้อย ในกรณีนี้เราทำอะไรผิด เราควรจะแก้ไขปัญหาด้วยวิธีที่สมบูรณ์มากขึ้นหรือไม่ดังนั้นเราจึงไม่สามารถเขียนโค้ดที่ไม่ดีและเขียนโค้ดที่เราเพิ่งเขียนเมื่อสัปดาห์ที่แล้ว? หรือเราควรทำอย่างนั้นต่อไปเพื่อให้แน่ใจว่ารหัสนั้นถูกเขียนใหม่ทั้งหมด? อะไรจะเป็นวิธีการที่คล่องตัวในการแก้ไขปัญหานี้?
22 agile  scrum 

6
บูรณาการอย่างต่อเนื่องสำหรับซอฟต์แวร์ทางวิทยาศาสตร์
ฉันไม่ใช่วิศวกรซอฟต์แวร์ ฉันเป็นนักเรียนปริญญาเอกในสาขาธรณีศาสตร์ เกือบสองปีที่แล้วฉันเริ่มเขียนโปรแกรมซอฟต์แวร์เชิงวิทยาศาสตร์ ฉันไม่เคยใช้การรวมอย่างต่อเนื่อง (CI) ส่วนใหญ่เป็นเพราะในตอนแรกฉันไม่รู้ว่ามันมีอยู่จริงและฉันเป็นคนเดียวที่ทำงานกับซอฟต์แวร์นี้ ในขณะนี้เนื่องจากฐานของซอฟต์แวร์กำลังเรียกใช้คนอื่นเริ่มสนใจและต้องการมีส่วนร่วมกับซอฟต์แวร์ แผนดังกล่าวคือบุคคลอื่น ๆ ในมหาวิทยาลัยอื่นกำลังนำส่วนเพิ่มเติมไปใช้กับซอฟต์แวร์หลัก (ฉันกลัวว่าพวกเขาสามารถแนะนำข้อบกพร่อง) นอกจากนี้ซอฟต์แวร์นั้นค่อนข้างซับซ้อนและยากที่จะทดสอบและฉันก็วางแผนที่จะทำงานต่อไป ด้วยเหตุผลสองประการนี้ฉันจึงคิดจะใช้ CI มากขึ้นเรื่อย ๆ เนื่องจากฉันไม่เคยมีการศึกษาวิศวกรซอฟต์แวร์และไม่มีใครรอบตัวฉันเคยได้ยินเกี่ยวกับ CI (เราเป็นนักวิทยาศาสตร์ไม่มีโปรแกรมเมอร์) ฉันพบว่ามันยากที่จะเริ่มต้นสำหรับโครงการของฉัน ฉันมีคำถามสองสามข้อที่ฉันต้องการคำแนะนำ: ก่อนอื่นคำอธิบายสั้น ๆ เกี่ยวกับการทำงานของซอฟต์แวร์: ซอฟต์แวร์ถูกควบคุมโดยไฟล์. xml ไฟล์เดียวที่มีการตั้งค่าที่จำเป็นทั้งหมด คุณเริ่มซอฟต์แวร์โดยเพียงแค่ส่งพา ธ ไปยังไฟล์. xml เป็นอาร์กิวเมนต์อินพุตและรันและสร้างไฟล์สองสามไฟล์ที่มีผลลัพธ์ การวิ่งครั้งเดียวสามารถใช้เวลา ~ 30 วินาที มันเป็นซอฟต์แวร์ทางวิทยาศาสตร์ ฟังก์ชั่นเกือบทั้งหมดมีพารามิเตอร์อินพุตหลายค่าซึ่งชนิดส่วนใหญ่เป็นคลาสที่ค่อนข้างซับซ้อน ฉันมีไฟล์. txt หลายไฟล์ที่มีแค็ตตาล็อกขนาดใหญ่ซึ่งใช้สร้างอินสแตนซ์ของคลาสเหล่านี้ ตอนนี้มาคำถามของฉัน: การทดสอบหน่วยการทดสอบบูรณาการการทดสอบแบบครบวงจร? : ซอฟต์แวร์ของฉันมีโค้ดประมาณ 30,000 บรรทัดพร้อมฟังก์ชั่นนับร้อยและ ~ 80 คลาส …

8
เมื่อความหลงใหลดั้งเดิมไม่ได้กลิ่นรหัสคืออะไร?
ฉันได้อ่านบทความจำนวนมากเมื่อเร็ว ๆ นี้ที่อธิบายครอบงำจิตใจดั้งเดิมเป็นกลิ่นรหัส มีประโยชน์สองประการในการหลีกเลี่ยงความหลงใหลดั้งเดิม: ทำให้โมเดลโดเมนชัดเจนยิ่งขึ้น ตัวอย่างเช่นฉันสามารถพูดคุยกับนักวิเคราะห์ธุรกิจเกี่ยวกับรหัสไปรษณีย์แทนที่จะเป็นสตริงที่มีรหัสไปรษณีย์ การตรวจสอบทั้งหมดอยู่ในที่เดียวแทนที่จะใช้ข้ามแอปพลิเคชัน มีบทความมากมายที่อธิบายเมื่อมันเป็นกลิ่นรหัส ตัวอย่างเช่นฉันสามารถเห็นประโยชน์ของการลบความหลงใหลดั้งเดิมสำหรับรหัสโพสต์เช่นนี้: public class Address { public ZipCode ZipCode { get; set; } } นี่คือตัวสร้างของรหัสไปรษณีย์: public ZipCode(string value) { // Perform regex matching to verify XXXXX or XXXXX-XXXX format _value = value; } คุณจะทำลายหลักการDRYโดยวางตรรกะการตรวจสอบความถูกต้องทุกที่ที่ใช้รหัสไปรษณีย์ อย่างไรก็ตามสิ่งที่เกี่ยวกับวัตถุต่อไปนี้: วันเดือนปีเกิด: ตรวจสอบว่ามากเกินใจและน้อยกว่าวันนี้วันที่ เงินเดือน: ตรวจสอบว่ามากกว่าหรือเท่ากับศูนย์ คุณจะสร้างวัตถุ DateOfBirth และวัตถุเงินเดือนหรือไม่ ประโยชน์คือคุณสามารถพูดคุยเกี่ยวกับพวกเขาเมื่ออธิบายรูปแบบโดเมน …

3
ทำไมคุณถึงเขียนหน่วยทดสอบสำหรับคอนโทรลเลอร์?
สำหรับฉันนี่คือการทดสอบหน่วยที่ไม่เกี่ยวข้องโดยสิ้นเชิงและฉันไม่เข้าใจว่าทำไมบางคนถึงใช้เวลาเขียนมันเนื่องจากมีค่าน้อยมากที่จะได้รับจากมัน ฉันจะรู้ได้อย่างสมบูรณ์แบบว่าตัวควบคุมนี้ส่งคืนชนิดที่ต้องการโดยดำเนินการวิธีการในเบราว์เซอร์ จริงๆแล้วคุณเชื่อหรือไม่ว่าการทดสอบจำเป็นสำหรับสิ่งนี้และเพราะเหตุใด public class ConstituencyControllerTests { private ConstituencyController _constituencyController; private Mock<IConstituencyService> _IConstituencyServiceMock; public ConstituencyControllerTests() { _IConstituencyServiceMock = new Mock<IConstituencyService>(); } [Test] public async Task I_Check_For_Return_Type_And_Result() { _constituencyController = new ConstituencyController( _IConstituencyServiceMock.Object ); var result = await _constituencyController.Get(); var content = ( (dynamic)result ).Content; Assert.IsEmpty( content ); Assert.IsInstanceOf( typeof( System.Web.Http.Results.OkNegotiatedContentResult<IEnumerable<ListOfConstituencies>> …

2
คำสั่ง CQRS ควรจะตรวจสอบและแปลงเป็นวัตถุโดเมนอย่างไร?
ฉันได้ปรับCQRS 1ของคนยากจนมาระยะหนึ่งแล้วเพราะฉันชอบความยืดหยุ่นในการมีข้อมูลละเอียดในแหล่งข้อมูลเดียวให้ความเป็นไปได้ที่ยอดเยี่ยมสำหรับการวิเคราะห์และเป็นการเพิ่มมูลค่าทางธุรกิจและเมื่อต้องการอีกอันสำหรับอ่านที่มีข้อมูล . แต่น่าเสียดายมากตั้งแต่ต้นฉันได้รับการดิ้นรนกับปัญหาที่ฉันควรวางตรรกะทางธุรกิจในสถาปัตยกรรมประเภทนี้ จากสิ่งที่ฉันเข้าใจคำสั่งหมายถึงการสื่อสารเจตนาและไม่มีความผูกพันกับโดเมนด้วยตัวเอง โดยทั่วไปจะเป็นข้อมูล (เป็นใบ้ - หากคุณต้องการ) ถ่ายโอนวัตถุ นี่คือการทำให้คำสั่งถ่ายโอนระหว่างเทคโนโลยีที่แตกต่างได้อย่างง่ายดาย เช่นเดียวกับเหตุการณ์ที่เป็นการตอบสนองต่อเหตุการณ์ที่เสร็จสมบูรณ์แล้ว ในแอปพลิเคชัน DDD ทั่วไปตรรกะทางธุรกิจจะอยู่ภายในเอนทิตีวัตถุค่ารูตรวมโดยรวมพวกเขามีทั้งข้อมูลและพฤติกรรม แต่คำสั่งไม่ใช่วัตถุโดเมนดังนั้นจึงไม่ควร จำกัด เฉพาะการแสดงข้อมูลโดเมนเพราะนั่นทำให้เครียดมากเกินไป ดังนั้นคำถามที่แท้จริงคือตรรกะตรงไหน? ฉันพบว่าฉันมักจะเผชิญกับการต่อสู้ครั้งนี้บ่อยที่สุดเมื่อพยายามสร้างการรวมที่ค่อนข้างซับซ้อนซึ่งกำหนดกฎบางอย่างเกี่ยวกับการรวมกันของค่านิยม นอกจากนี้เมื่อสร้างแบบจำลองวัตถุโดเมนฉันชอบที่จะทำตามกระบวนทัศน์ที่ล้มเหลวอย่างรวดเร็วรู้ว่าเมื่อวัตถุมาถึงวิธีการที่มันอยู่ในสถานะที่ถูกต้อง สมมติว่าการรวมCarใช้สององค์ประกอบ: Transmission, Engine. วัตถุทั้งสองTransmissionและEngineค่าจะแสดงเป็นประเภทซุปเปอร์และมีตามประเภทย่อยAutomaticและManualการส่งสัญญาณหรือPetrolและElectricเครื่องยนต์ตามลำดับ ในโดเมนนี้การใช้ชีวิตที่สร้างขึ้นอย่างประสบความสำเร็จTransmissionไม่ว่าจะเป็นAutomaticหรือManualหรือประเภทใดประเภทหนึ่งEngineก็ใช้ได้ดี แต่การCarรวมรวมจะมีกฎใหม่สองสามข้อใช้งานได้เฉพาะเมื่อTransmissionและEngineวัตถุถูกใช้ในบริบทเดียวกัน กล่าวคือ: เมื่อรถใช้เครื่องยนต์ชนิดส่งได้รับอนุญาตเพียงอย่างเดียวคือElectricAutomatic เมื่อรถใช้เครื่องยนต์มันอาจจะมีประเภทของการอย่างใดอย่างหนึ่งPetrolTransmission ฉันสามารถตรวจจับการละเมิดการรวมกันของส่วนประกอบนี้ในระดับของการสร้างคำสั่ง แต่ตามที่ฉันได้ระบุไว้ก่อนหน้านี้จากสิ่งที่ฉันเข้าใจว่าไม่ควรทำเพราะคำสั่งนั้นจะมีตรรกะทางธุรกิจซึ่งควร จำกัด ชั้นโดเมน หนึ่งในตัวเลือกคือการย้ายการตรวจสอบความถูกต้องทางตรรกะทางธุรกิจไปยังตัวตรวจสอบคำสั่งด้วยตนเอง แต่ดูเหมือนจะไม่ถูกต้องเช่นกัน มันรู้สึกเหมือนว่าฉันจะแยกแยะคำสั่งตรวจสอบคุณสมบัติที่เรียกคืนโดยใช้ getters และเปรียบเทียบมันภายใน validator และตรวจสอบผลลัพธ์ เสียงกรีดร้องดังกล่าวเป็นการละเมิดกฎหมายของ Demeterสำหรับฉัน ยกเลิกตัวเลือกการตรวจสอบความถูกต้องที่กล่าวถึงเพราะดูเหมือนว่าจะไม่สามารถใช้งานได้ดูเหมือนว่ามีใครควรใช้คำสั่งและสร้างการรวมจากมัน แต่ตรรกะนี้ควรอยู่ที่ไหน ควรอยู่ในตัวจัดการคำสั่งที่รับผิดชอบการจัดการคำสั่งที่เป็นรูปธรรมหรือไม่? หรือควรอยู่ในเครื่องมือตรวจสอบคำสั่ง (ฉันไม่ชอบวิธีการนี้เช่นกัน) ขณะนี้ฉันกำลังใช้คำสั่งและสร้างการรวมจากคำสั่งภายในตัวจัดการคำสั่งที่รับผิดชอบ แต่เมื่อฉันทำสิ่งนี้ฉันควรจะมีเครื่องมือตรวจสอบคำสั่งมันจะไม่มีอะไรเลยเพราะCreateCarคำสั่งควรมีอยู่แล้วมันจะมีส่วนประกอบที่ฉันรู้ว่าถูกต้องในกรณีที่แยกต่างหาก …

5
Microservices: การจัดการความสอดคล้องในที่สุด
สมมติว่าเรามีฟังก์ชั่นที่อัปเดตรหัสผ่านของผู้ใช้ เมื่อคลิกปุ่ม 'อัปเดตรหัสผ่าน' จะมีการส่ง UpdatePasswordEvent ไปยังหัวข้อที่สมัครใช้บริการอื่น 3 บริการ: บริการที่อัพเดตรหัสผ่านของผู้ใช้จริง บริการที่อัพเดตประวัติรหัสผ่านของผู้ใช้ บริการที่ส่งอีเมลแจ้งให้ผู้ใช้ทราบว่ารหัสผ่านของเขาถูกเปลี่ยน จากสิ่งที่ฉันเข้าใจเกี่ยวกับความสอดคล้องในที่สุดบริการเหล่านี้ (ผู้บริโภค) จะได้รับเหตุการณ์ในเวลาเดียวกันและดำเนินการแยกต่างหากซึ่งในสถานการณ์ที่ดีจะนำไปสู่ข้อมูลที่สอดคล้องกัน อย่างไรก็ตามจะเกิดอะไรขึ้นถ้าบริการล้มเหลวในการประมวลผลเหตุการณ์ เช่นการตัดการเชื่อมต่ออย่างฉับพลันข้อผิดพลาดของฐานข้อมูล ฯลฯ ... รูปแบบ / การปฏิบัติที่ดีในการจัดการกับความล้มเหลวของธุรกรรมคืออะไร ฉันกำลังคิดที่จะสร้าง RollbackTopic ซึ่งหากมีเหตุการณ์ใดที่ไม่สามารถประมวลผลได้ RollbackEvent จะถูกสร้างขึ้นในหัวข้อที่ "บริการการย้อนกลับ" จะทำงานและเปลี่ยนกลับเป็นข้อมูล

1
การอนุมาน Hindley-Milner สามารถทำงานกับภาษา Go ได้หรือไม่
ฉันอ่านแล้วว่าHindley-Milnerไม่ทำงานกับระบบพิมพ์ที่มีคลาสย่อยและมีคุณสมบัติของระบบประเภทอื่น ๆ ที่ใช้งานไม่ได้กับมัน ไปในขณะนี้มีข้อสรุปประเภท จำกัด มากใน:=ผู้ประกอบการ แต่ Go ไม่ได้มี subclasses ในความหมายดั้งเดิมมีเพียงอินเตอร์เฟสที่มีลักษณะคล้ายกับคลาสของ Haskell ซึ่งทำงานได้ดีกับการอนุมาน Hindley-Milner ดังนั้นการอนุมานของ Hindley-Milner สามารถทำงานได้ในหลักการของ Go แบบเดียวกับ Haskell หรือไม่? หรือไปมีคุณสมบัติอื่น ๆ ที่ทำลายมันได้หรือไม่ (ในทางกลับกัน Haskell ยังมีคุณสมบัติบางอย่างที่ไม่สามารถใช้กับ Hindly-Milner ได้หากคุณใช้สิ่งที่คุณต้องพิมพ์ด้วยตนเองในส่วนของโปรแกรม)

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.