دسترسی نامحدود
برای کاربرانی که ثبت نام کرده اند
برای ارتباط با ما می توانید از طریق شماره موبایل زیر از طریق تماس و پیامک با ما در ارتباط باشید
در صورت عدم پاسخ گویی از طریق پیامک با پشتیبان در ارتباط باشید
برای کاربرانی که ثبت نام کرده اند
درصورت عدم همخوانی توضیحات با کتاب
از ساعت 7 صبح تا 10 شب
ویرایش: 1 نویسندگان: Raju Gandhi, Mark Richards, Neal Ford سری: ISBN (شابک) : 1098134354, 9781098134358 ناشر: O'Reilly Media سال نشر: 2024 تعداد صفحات: 486 زبان: English فرمت فایل : PDF (درصورت درخواست کاربر به PDF، EPUB یا AZW3 تبدیل می شود) حجم فایل: 50 مگابایت
در صورت تبدیل فایل کتاب Head First Software Architecture: A Learner's Guide to Architectural Thinking به فرمت های PDF، EPUB، AZW3، MOBI و یا DJVU می توانید به پشتیبان اطلاع دهید تا فایل مورد نظر را تبدیل نمایند.
توجه داشته باشید کتاب Head First Software Architecture: راهنمای یادگیرنده برای تفکر معماری نسخه زبان اصلی می باشد و کتاب ترجمه شده به فارسی نمی باشد. وبسایت اینترنشنال لایبرری ارائه دهنده کتاب های زبان اصلی می باشد و هیچ گونه کتاب ترجمه شده یا نوشته شده به فارسی را ارائه نمی دهد.
Cover Title Page Copyright About the Authors Table of Contents Intro Chapter 1: Software Architecture Demystified Building your understanding of software architecture Building plans and software architecture The dimensions of software architecture Puzzling out the dimensions The first dimension: Architectural characteristics The second dimension: Architectural decisions The third dimension: Logical components The fourth dimension: Architectural styles A design perspective An architectural perspective The spectrum between architecture and design Where along the spectrum does your decision fall? Strategic versus tactical High versus low levels of effort Significant versus less-significant trade-offs Putting it all together You made it! Chapter 2: Architectural Characteristics Causing Lafter What are architectural characteristics? Defining architectural characteristics Characteristics are nondomain design considerations Characteristics influence architectural structure Limit characteristics to prevent overengineering Consider explicit and implicit capabilities The International Zoo of “-ilities” Process architectural characteristics Structural architectural characteristics Operational architectural characteristics Cross-cutting architectural characteristics Sourcing architectural characteristics from the problem domain Sourcing architectural characteristics from environmental awareness Sourcing architectural characteristics from holistic domain knowledge Composite architectural characteristics Priorities are contextual Lost in translation Architectural characteristics and logical components Balancing domain considerations and architectural characteristics Limiting architectural characteristics Chapter 3: The Two Laws of Software Architecture It starts with a sneaker app What do we know so far? Communicating with downstream services Analyzing trade-offs Trade-off analysis: Queue edition Trade-off analysis: Topic edition The first law of software architecture It always comes back to trade-offs Making an architectural decision What else makes a decision architectural? The second law of software architecture Architectural decision records (ADRs) Writing ADRs: Getting the title right Writing ADRs: What’s your status? Writing ADRs: Establishing the context Writing ADRs: Communicating the decision Writing ADRs: Considering the consequences Writing ADRs: Ensuring governance Writing ADRs: Closing notes The benefits of ADRs Two Many Sneakers is a success Chapter 4: Logical Components Logical components revisited Name that component Adventurous Auctions goes online Logical versus physical architecture Creating a logical architecture Step 1: Identifying initial core components Workflow approach Actor/action approach The entity trap Step 2: Assign requirements Step 3: Analyze roles and responsibilities Sticking to cohesion Step 4: Analyze characteristics The Bid Capture component Component coupling Afferent coupling Efferent coupling Measuring coupling A tightly coupled system Applying the Law of Demeter A balancing act Some final words about components Chapter 5: Categorization and Philosophies There are lots of architectural styles The world of architectural styles Partitioning: Technical versus domain Deployment model: Monolithic versus distributed Monolithic deployment models: The pros Monolithic: The cons Distributed deployment models: The pros Distributed deployment models: The cons And that’s a wrap! Chapter 6: Layered Architecture Naan & Pop: Gathering requirements Design patterns redux Layering MVC Layering it on Translating layers into code Domains, components, and layers Drivers for layered architecture Layers, meet the real world: Physical architectures Physical architecture trade-offs One final caveat about domain changes Layered architecture superpowers Layered architecture kryptonite Layered architecture star ratings Wrapping it up Chapter 7: Driven by the Domain Modular monolith? Domain pains changes Why modular monoliths? Show me the code! Keeping modules modular Taking modularity all the way to the database Beware of joins Modular monolith superpowers Modular monolith kryptonite Modular monolith star ratings Naan & Pop is delivering pizza! Chapter 8: Microkernel Architecture The benefits of Going Green The two parts of microkernel architectures The spectrum of “microkern-ality” Device assessment service core Encapsulated versus distributed plugins Plugin communication Cubicle conversation Plugin contracts Going Green goes green Microkernel superpowers Microkernel kryptonite Microkernel star ratings Wrapping it up Chapter 9: Do It Yourself Making travel easier TripEZ’s user workflow Planning the architecture The architects’ roadmap Step 1: Identify architectural characteristics Step 2: Identify logical components Step 3: Choose an architectural style Step 4: Document your decision Step 5: Diagram your architecture There are no right (or wrong) answers Chapter 10: Microservices Architecture Are you feeling okay? What’s a microservice? It’s my data, not yours How micro is “micro”? Granularity disintegrators Why should you make microservices smaller? Granularity integrators Why should you make microservices bigger? It’s all about balance Sharing functionality Code reuse with a shared service Code reuse with a shared library Managing workflows Orchestration: Conducting microservices Choreography: Let’s dance Microservices architecture superpowers Microservices architecture kryptonite Microservices star ratings Wrapping it up Chapter 11: Event-Driven Architecture Too slow Speeding things up Der Nile flows faster than ever What is an event? Events versus messages Initiating and derived events Is anyone listening? Asynchronous communication Fire-and-forget Asynchronous for the win Synchronous for the win Database topologies Monolithic database Domain-partitioned databases Database-per-service EDA versus microservices Hybrids: Event-driven microservices Event-driven architecture superpowers Event-driven architecture kryptonite Event-driven architecture star ratings Putting it all together Wrapping up Chapter 12: Testing Your Knowledge Welcome to Make the Grade Student testing workflow Planning the architecture The architects’ roadmap Step 1: Identify architectural characteristics Step 2: Identify logical components Step 3: Choose an architectural style Step 4: Document your decision Step 5: Diagram your architecture There are no right (or wrong) answers! Appendix: Leftovers #1 The coding architect #2 Expectations for architects #3 The soft skills of architecture #4 Diagramming techniques #5 Knowledge depth versus breadth #6 Practicing architecture with katas Index