คำถามติดแท็ก modularization

ฉันเพิ่งอ่านบทความที่ยอดเยี่ยมนี้ในสถาปัตยกรรม microservice: http://www.infoq.com/articles/microservices-intro มันระบุว่าเมื่อคุณโหลดหน้าเว็บใน Amazon แล้วไมโครไซต์กว่า 100 รายการจะร่วมมือเพื่อให้บริการหน้านั้น บทความนั้นอธิบายว่าการสื่อสารระหว่างไมโครไซต์ทั้งหมดสามารถทำได้ผ่าน API เท่านั้น คำถามของฉันคือเหตุผลที่ไม่ดีที่จะบอกว่าการเขียนฐานข้อมูลทั้งหมดสามารถทำได้ผ่าน API เท่านั้น แต่คุณสามารถอ่านได้โดยตรงจากฐานข้อมูลของบริการไมโครต่างๆ ตัวอย่างเช่นสามารถพูดได้ว่ามีเพียงไม่กี่มุมมองฐานข้อมูลที่สามารถเข้าถึงได้นอกบริการไมโครเพื่อให้ทีมที่ดูแลบริการไมโครรู้ว่าตราบใดที่พวกเขารักษามุมมองเหล่านี้เหมือนเดิมแล้วพวกเขาสามารถเปลี่ยนโครงสร้างฐานข้อมูลของบริการไมโคร ต้องการ. ฉันทำอะไรบางอย่างหายไปหรือเปล่า มีเหตุผลอื่นอีกไหมทำไมข้อมูลควรอ่านผ่าน API เท่านั้น? บริษัท ของฉันเล็กกว่า Amazon อย่างมาก (และจะเป็นเสมอ) และจำนวนผู้ใช้สูงสุดที่เราสามารถมีได้ประมาณ 5 ล้านคน

64 architecture  web-services  soa  microservices  modularization 

หลังจากการอภิปรายและการวิจัยนาน 3 เดือนในการเลือกระหว่าง React (กับ Redux) และ Angular 2 ทีม front-end ใน บริษัท ของฉันได้สรุปว่าจะไปกับ Angular 2 (เนื่องจากมันเหมาะสมกับปัญหาของเรามากขึ้น) เราเข้าสู่ธุรกิจแอพระดับองค์กรซึ่งปัจจุบันประกอบด้วยเทคโนโลยี Front-End ที่แตกต่างกันมากมาย (ในขณะที่มีแบ็กเอนด์ RESTful ทั้งหมด) และเราต้องการแทนที่ทั้งหมดและมีเทคโนโลยีเดียวที่จะทำให้การฝึกอบรมและการควบคุมคุณภาพในอนาคตง่ายขึ้น ด้วยลักษณะของผลิตภัณฑ์ของเรามันมีมากมายและมีโมดูลอยู่ภายในซึ่งอยู่ในโดเมนอื่นและสามารถทำเป็นแอพแบบสแตนด์อโลนได้ แต่ตัวผลิตภัณฑ์นั้นใช้ URL เดียว ตัวอย่าง; เรียกผลิตภัณฑ์ของฉันเป็น SuperApp ในฐานะที่เป็น UI นั้น SuperApp มีระบบเข้าสู่ระบบมาตรฐานและการนำทางไปยังโมดูลย่อย / ผลิตภัณฑ์ย่อยเช่นเวิร์กโฟลว์ปรากฏดังต่อไปนี้ SuperApp ตรวจสอบผู้ใช้ ลืมรหัสผ่านของวิซาร์ด เข้าถึงหน้าสาธารณะโดยไม่ต้องตรวจสอบสิทธิ์ ผู้ใช้รับรองความถูกต้อง ระบบนำทาง บ้าน Sub-Product1 Sub-Product2 Sub-Product3 ข้อมูลส่วนตัว ... …

17 architecture  web-applications  enterprise-architecture  angular2  modularization 

ก่อนอื่นฉันอ่านข้อความที่ตัดตอนมาของ Edsger W. Dijkstra ในปี 1974 "ในบทบาทของความคิดทางวิทยาศาสตร์": ให้ฉันพยายามอธิบายให้คุณฟังว่าอะไรคือรสนิยมของฉันสำหรับการคิดที่ชาญฉลาด มันคือว่าเราเต็มใจที่จะศึกษาในเชิงลึกในแง่มุมของเนื้อหาที่แยกออกมาเพื่อความมั่นคงของตัวเองตลอดเวลาที่รู้ว่าคนนั้นครอบครองตัวเองด้วยแง่มุมใดด้านหนึ่งเท่านั้น เรารู้ว่าโปรแกรมจะต้องถูกต้องและเราสามารถศึกษาได้จากมุมมองนั้นเท่านั้น เรารู้ด้วยว่ามันควรจะมีประสิทธิภาพและเราสามารถศึกษาประสิทธิภาพของมันในอีกวันหนึ่ง ในอีกอารมณ์หนึ่งเราอาจถามตัวเองว่าและถ้าเป็นเช่นนั้น: ทำไมโปรแกรมนี้จึงเป็นที่ต้องการ แต่ไม่มีสิ่งใดได้รับ - ในทางตรงกันข้าม! - โดยจัดการกับแง่มุมต่าง ๆ เหล่านี้พร้อมกัน บางครั้งฉันก็เรียกว่า "การแยกความกังวล" ซึ่งแม้ว่าจะเป็นไปไม่ได้อย่างสมบูรณ์ก็ตาม ยังเป็นเทคนิคเดียวที่มีอยู่สำหรับการจัดลำดับความคิดของคน ๆ หนึ่งที่ฉันรู้ นี่คือสิ่งที่ฉันหมายถึงโดย "การมุ่งความสนใจไปที่บางแง่มุม": มันไม่ได้หมายถึงการเพิกเฉยต่อแง่มุมอื่น ๆ มันแค่ทำความยุติธรรมกับข้อเท็จจริงที่ว่าจากมุมมองของแง่มุมนี้มุมมองอื่น ๆ นั้นไม่เกี่ยวข้อง มันเป็นหนึ่งในใจและหลายแทร็คพร้อมกัน ฉันเห็นการแยกข้อกังวลที่ทันสมัยพูดคุยเกี่ยวกับการทำให้โค้ดของคุณเป็นโมดูล อย่างไรก็ตามการอ่านคำพูดข้างต้นฉันเข้าใจว่านี่คือการมุ่งความคิดของคุณไปที่งานหนึ่งโดยเฉพาะในขณะที่ไม่ได้มุ่งเน้นด้านอื่น ๆ นี่ไม่ได้แปลว่าจำเป็นต้องแบ่งรหัสออกเป็นส่วนย่อย ๆ กล่าวคือมีโค้ดอยู่ข้างหน้าคุณว่าในไฟล์เดียวมีแนวคิดของมุมมองพื้นที่เก็บข้อมูลตัวควบคุมการจัดการเหตุการณ์โรงงาน ฯลฯ ทั้งหมดในไฟล์เดียว สำหรับตัวอย่างสั้น ๆ นี่คือโค้ดบางส่วนที่มีการเข้าถึงข้อมูลและมุมมอง (เอาต์พุต): $sql = "SELECT * …

9 design  source-code  separation-of-concerns  modularization  dijkstra