software architecture in practice second edition

multiple iterations and even multiple releases. A good software architecture is not an overnight program. In the framework design and development process, we should try to avoid waterfall thinking, through an "architectural design phase" to complete the system architecture design and even detailed design, and then according to the

specific work how to apply, not too much attention to the concept and theory, so we ask this question, I although the knowledge of the concept of software architecture and ideological understanding there is a certain ambiguity, but I also can not explain to you understand. But I use one of the projects mentioned in the example, from a number of points to point out that everyone's understanding and correct

1.1 of three questionsTo master the demand analysis, we need to master three problem solving methods. How are requirements obtained? Demand development = Vision Analysis + Demand analysis How to judge the demand is not complete? Functions, quality, constraints three types of requirements How do I convert from requirements to design? functionality, quality, and constraints have different effects on the architecture. 1.2 General di

Before we introduce an instance, we need to review and learn more about layered architecture. "Layer" is a kind of architecture pattern [POSA1], and is one of the most widely used and flexible models by software practitioners. Remember on the CSDN, often have a friend asked: "What is stratification?" Why should I be layered? Is the three-tier

The last time I had the honor to introduce the software architecture design "Seven kinds of weapons", for this "Seven kinds of weapons" is a long process of cultivation, in addition to the need for continuous learning theory, principles, but also constantly in the software architecture design work to

user stories under that feature.Iv. Scrum User Story layerUser stories are a description of the functional points that are valuable to users, systems, or software purchasers, simply described as user needs, with a few sentences of the user's everyday language, the estimated workload can be completed in an iterative plan, and if the estimated workload is too large, it can be split into smaller user stories.Each user story contains multiple related tas

their energy is more focused on the business.As for the other aspects of a technology, such as how to deploy, the deep analysis of open source software, and so on, I do not intend to do in this book in-depth elaboration, the reader if interested can learn in-depth. I hope that in this book can give the reader a blueprint for the development of the background of the app.This book is divided into 4 main parts.The 1th to 3rd chapter: the application bac

Readers may think that "the software architecture is too abstract, too theoretical, and there is nothing practical ". However, any practice must be guided by the theory. If we abandon the theoretical basis and blindly pursue practicality, we can only swallow the question.A core issue in software

, demand symposium, observing user workflow, prototyping method, use case-based approach.The fifth chapter, the formal method in software engineering from the broad sense, formal method refers to the method of discrete mathematics to solve the problem of software engineering field, mainly including the establishment of accurate mathematical model and analysis of the model activities. In the narrow sense, th

Preface I haven't updated my blog for a while. On the one hand, because of busy work, on the other hand, I have been insisting on designing and improving the application system development framework based on DDD recently.Apworks. I have read my field-driven design case: Tiny Library SeriesArticleMy friends must have heard of the apworks framework. Although this framework is not yet mature enough to be used in real system development, it has implemented the cqrs