tgoop.com/emacsway_log/1436
Last Update:
Когда-то я сказал, что "архитектура - есть суть разрешение противоречий".
После долгих исследований литературы, публичных и личных обсуждений вопроса о том, что такое архитектура, я еще больше укореняюсь именно в таком толковании. И этот пост наглядно демонстрирует мои мысли:
https://www.tgoop.com/systemswing/132
Попутно он хорошо демонстрирует применение на практике первого и второго законов диалектики.
[UPDATE]:
Architecture Definition Isn’t Just Design
———————
A common question that arises is whether architecture definition is “just” part of design or whether there is something more to it. It’s true that architecture definition incorporates elements of design and also of requirements analysis, but it is a separate activity from each of these.
———————
• Design is an activity focused on the solution space and targeted primarily at one group of people—the developers. It works within a clearly defined set of constraints (the system’s requirements) and is essentially a process of translating these into the specifications for a conformant system. Historically, design has tended not to focus as much on the needs of other groups such as operations or support, assuming that their needs have been captured in the requirements specifications (or often ignoring them altogether).
• Requirements analysis, on the other hand, is an activity focused on the problem space that (in its purest forms) ignores the needs and constraints of groups like developers and systems administrators because it defines what is desired rather than what is possible. It also works within a clearly defined set of constraints (the system’s required scope), although within these constraints it tends to have much more freedom than the design process does.
———————
Architecture definition resolves this tension by bridging the gap between the problem and solution spaces. Its focus is to understand the needs of everyone who has an interest in the architecture, to balance these needs, and to identify an acceptable set of tradeoffs between these where necessary. The tradeoffs take into account the constraints that exist (e.g., technical feasibility, timescales, resources, deployment environment, costs, and so on).
-- "Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives" 2nd edition by Nick Rozanski, Eóin Woods
BY emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Share with your friend now:
tgoop.com/emacsway_log/1436