硬件体系结构模型
As an architect, how often are you thinking about business models? If every significant architecture decision has business consequences, then knowing the business model and which trade-offs to choose is maybe the most important skill of architects.
作为一名架构师，您多久考虑一次业务模型？ 如果每个重要的架构决策都会带来业务后果，那么了解业务模型以及选择哪些折衷方案可能是架构师最重要的技能。
But what is the actual relationship between a business model and a software architecture? I’ve been thinking about this a lot because I want a deeper understanding of the implications. If I know how decisions in one space affect the other, I’m going to make better architectural decisions.
但是，业务模型和软件体系结构之间的实际关系是什么？ 我已经考虑了很多，因为我希望对含义有更深入的了解。 如果我知道一个空间中的决策如何影响另一空间，那么我将做出更好的架构决策。
It’s not just about business models and architecture, though. There are other systems involved in this tangled relationship. A software system is a model of a domain. Is the business domain the same as the business model? What about the organisation? Conway’s Law suggests it is the biggest influence on architecture.
但是，这不仅与业务模型和体系结构有关。 这种纠结的关系还涉及其他系统。 软件系统是领域的模型。 业务领域与业务模型相同吗？ 那组织呢？ 康威定律表明，这是对建筑的最大影响。
软件架构和业务模型 (Software Architecture And Business Models)
A business model is a set of decisions about how to create value and who to create it for. The Business Model Canvas is my favourite tool for thinking about business models.
商业模型是关于如何创造价值以及为谁创造价值的一系列决策。 商业模型画布是我最喜欢的商业模型思考工具。
If you’re not familiar, here’s a quick definition of the main elements:
如果您不熟悉，这里是主要元素的快速定义：
Customers Segments = who do we provide value for?Value Propositions = what value do we create?Key Activities = how do we create the value?Revenue Streams = where does the money come from?
客户群 =我们为谁提供价值？ 价值主张 =我们创造什么价值？ 关键活动 =我们如何创造价值？ 收入流 = 哪里的钱从何而来？
How does all of this relate to the software architecture?
所有这些与软件体系结构有何关系？
The software architecture is the how. It is the means by which a company creates and delivers some or all of the value proposition to the customer segments.
软件体系结构是如何实现的 。 这是公司创造并向客户群交付部分或全部价值主张的手段。
含义 (Implications)
The goal of a software architecture is to do the how as effectively and efficiently as possible: to create the most value for the customer segments while minimising the costs and maximising the revenue.
软件体系结构的目标是尽可能有效和高效地做如何 ：同时最大限度地降低成本和最大化收入，为客户创造段最大的价值。
So what is the domain?
那么什么是域？
商业模式与商业领域 (Business Model vs Business Domain)
The business domain (aka problem domain, problem space) is a sub-set of the world which the business model depends on. A domain is composed of different types of concepts, including:
业务域(又称问题域，问题空间)是业务模型所依赖的世界的子集。 域由不同类型的概念组成，包括：
Entities = things with a lifecycle, akin to a state machine, like a customer or an order Attributes = characteristics that belong to or describe something else, like a person’s eye colourRules = a way to determine what should happen in a given situation, like a legal requirement that citizens must be 18 years old to purchase alcoholProcesses = a sequence of steps involving entities, attributes, and rules, like a job application process
实体 =具有生命周期的事物(类似于状态机，例如客户或订单) 属性 =属于或描述其他事物的特征(例如人的眼睛颜色) 规则 =确定在给定情况下应该发生什么的方法法律要求公民必须年满18岁才能购买酒类流程 =一系列涉及实体，属性和规则的步骤，例如工作申请流程
Customer segments are Entities in the domain. Key activities are processes in the domain. Financial transactions which generate revenue are processes in the domain involving rules and entities
客户群是域中的实体。 关键活动是领域中的流程。 产生收入的金融交易是涉及规则和实体的领域中的流程
Therefore, a business model depends on a problem domain. A business looks at a certain domain and creates a business model as a way of creating a profitable/sustainable business using the entities, rules, and processes in the domain.
因此，业务模型取决于问题域。 企业着眼于某个特定领域并创建业务模型，以作为使用该领域中的实体，规则和流程来创造盈利/可持续业务的一种方式。
含义 (Implications)
A deeper understanding of the business domain means that business model design can be information rich increasing the chances of making good decisions.
对业务领域的更深入了解意味着业务模型设计可以包含丰富的信息，从而增加了制定良好决策的机会。
软件体系结构和业务领域 (Software Architecture And Business Domains)
A software architecture has to implement the domain concepts in order to deliver the how of the business model. There are an unlimited number of ways to model a business domain, however. It is not a deterministic, sequential process.
软件体系结构必须实现，以实现商业模式的如何领域的概念。 但是，有无数种方法可以为业务领域建模。 这不是确定性的顺序过程。
A large domain must be decomposed into software sub-systems. Where should the boundaries be? Which responsibilities should live in each sub-system? There are many choices to make and the arbiter is the business model.
必须将一个大域分解为软件子系统。 边界应该在哪里？ 每个子系统应承担哪些责任？ 有许多选择，而仲裁者就是商业模型。
A software architecture, therefore, is an opinionated model of the business domain which is biased towards maximising the business model.
因此，软件体系结构是业务领域的自以为是的模型，该模型倾向于最大化业务模型。
含义 (Implications)
When software systems align poorly with the business domain, changes become harder and the business model is less successful.
当软件系统与业务领域的协调性很差时，变更会变得更加困难，并且业务模型的成功性也会降低。
When developers have to mentally translate from business language to the words in code it takes longer and mistakes are more likely. When new pieces of work always slice across-multiple sub-systems, it takes longer to make changes and deploy them.
当开发人员必须从思维上将业务语言转换为代码中的单词时，它需要更长的时间，并且更容易出错。 当新的工作总是跨越多个子系统时，进行更改和部署它们将花费更长的时间。
It is, therefore, fundamentally important to align the architecture and the domain as well as possible. However, due to the ambiguity of modelling a domain in code, each choice be anchored to the business model: the way of modelling the domain that best suits the business model is the right choice.
因此，从根本上使架构和域保持一致至关重要。 但是，由于在代码中对域进行建模的模棱两可，因此每个选择都应锚定到业务模型：最适合业务模型的域建模方法是正确的选择。
软件架构与组织架构 (Software Architecture vs Organisation Architecture)
Conway’s Law implies that the way teams are organized and communicate will be mirrored in the architecture of the software system. So the relationship is that organization architecture influences the shape and communication paths in the software architecture.
康韦定律意味着，团队的组织和沟通方式将反映在软件系统的体系结构中。 因此，关系是组织架构会影响软件架构中的形状和通信路径。
含义 (Implications)
The implications of Conway’s Law are talked about widely. In effect, design your architecture and teams collectively otherwise the architecture of the software will conform to the architecture of the organisation and it may be a painful journey.
康韦定律的含义被广泛讨论。 实际上，请共同设计您的体系结构和团队，否则软件的体系结构将与组织的体系结构保持一致，这可能会很痛苦。
Remember, the software architecture is a model of the domain. The boundaries in the software should be designed around domain concepts biased towards the business model. So the architecture of the teams must also follow the boundaries in the domain.
记住，软件架构是领域的模型。 软件的边界应围绕偏向业务模型的领域概念进行设计。 因此，团队的架构也必须遵循领域的界限。
Teams, however, have constraints. There are limitations to how many lines of code and software systems one person can maintain. So the architecture of the organisation also influences the architecture of the software…. software architecture is a compromise between the ideal domain boundaries and the needs of the teams building the architecture.
但是，团队有约束。 一个人可以维护多少行代码和软件系统存在限制。 因此，组织的体系结构也会影响软件的体系结构……。 软件体系结构是理想域边界与构建体系结构团队的需求之间的折衷方案 。
软件架构vs组织vs用户体验 (Software Architecture vs Organisation vs User Experience)
A software architecture exposes its value to the world via user experiences (UX). A web page, a mobile app, an API, a wearable device, and many other kinds too.
软件体系结构通过用户体验(UX)向世界展示其价值。 网页，移动应用，API，可穿戴设备以及许多其他类型。
Is the UX simply a way of exposing an architecture, or, does the UX make demands in this complicated relationship as well?
UX仅仅是暴露架构的一种方式，还是UX在这种复杂的关系中也提出了要求？
UX plays a significant role in determining team structure. There is often a debate between dedicated frontend teams vs full stack teams who own a full slice of UI all the way through the domain and the database. Often full stack teams use micro-frontends which is an architectural decision.
UX在确定团队结构方面起着重要作用。 专门的前端团队与在整个域和数据库中拥有一整套UI的完整堆栈团队之间经常会发生争论。 全栈团队通常使用微前端，这是一个体系结构决策。
含义 (Implications)
Dedicated frontend vs full-stack teams is a choice which impacts the organisation and the software architecture. And it also affects the cognitive load of teams. So if a team is full stack, using some of their cognitive load means they cannot own as much of the domain. This may impact the domain boundaries in the architecture.
专门的前端团队和全栈团队是影响组织和软件体系结构的选择。 这也影响团队的认知负担。 因此，如果团队是满员，那么利用他们的一些认知负荷就意味着他们无法拥有那么多领域。 这可能会影响体系结构中的域边界。
建筑与技术 (Architecture And Technology)
We can’t forget about technology. A software architecture is implemented using programming language technology and runs on cloud platforms. The domain has to be expressed as code and written by the teams in the organization.
我们不能忘记技术。 使用编程语言技术实现软件体系结构，并在云平台上运行。 该域必须用代码表示，并由组织中的团队编写。
As code gets older it becomes harder to change. Technologies eventually become redundant and need to be replaced by newer technologies which enable code be to developed more rapidly.
随着代码变老，更改变得越来越困难。 技术最终变得多余，需要用更新的技术代替，这些新技术可以使代码更快地开发。
含义 (Implications)
Coupling in the software may impact team boundaries. If parts of the code are too tightly coupled or shaped around hard-to-replace technologies, they cannot easily be decoupled to match the ideal domain and team boundaries. Therefore, the domain and team boundaries must conform to the legacy architecture and not vice-versa.
软件中的耦合可能会影响团队边界。 如果代码的某些部分过于紧密地耦合在一起，或者围绕难以替换的技术而成形，那么它们就很难轻易地分离出来以匹配理想的领域和团队边界。 因此，域和团队的边界必须符合传统架构，反之亦然。
There is great value in designing boundaries well up-front because they will be hard to change later. There is also great value in keeping the code supple and well maintained so it is easy to change because no up-front design will ever be perfect.
提前设计边界非常有价值，因为以后很难更改它们。 保持代码柔顺和良好维护也很有价值，因此很容易更改，因为没有任何前期设计会是完美的。
一切都在变化 (Everything Changes, All The Time)
There is one final thing to consider. Everything is always changing. The needs of the users in the domain are changing. People expect a constant stream of newer and better innovations. Companies are continuously striving to meet demand with sustaining and disruptive innovation.
还有最后一件事要考虑。 一切总是在变化。 域中用户的需求正在变化。 人们期望不断有更新更好的创新。 公司通过持续不断的颠覆性创新不断努力满足需求。
Attitudes in society are progressing. The environment is changing (Covid, global warming). Laws and regulations are changing.
社会上的态度正在进步。 环境正在发生变化(Covid，全球变暖)。 法律法规正在变化。
含义 (Implications)
Businesses have to constantly be looking to the future. How do they continue to maintain existing revenue streams while also finding new revenue streams? Business have to be aware of society and their competitors and evolve their business models to stay relevant.
企业必须不断地展望未来。 他们如何继续维持现有收入来源，同时又找到新的收入来源？ 企业必须意识到社会及其竞争对手，并发展其业务模型以保持相关性。
A software architecture has to be flexible to enable the business to explore new revenue streams and to flex as the domain constantly evolves.
软件体系结构必须具有灵活性，以使企业能够探索新的收入来源并随着领域的不断发展而灵活变通。
软件架构的范围很大 (The Scope of Software Architecture is Big)
A software architecture has a strong relationship to the business model, the domain, the organisation, the user experience, the environment, and it doesn’t stop there.
软件体系结构与业务模型，域，组织，用户体验，环境有着密切的关系，并且不止于此。
Software architecture is a huge compromise. Trying to find the least bad solution in a tangled web of love/hate relationships.
软件体系结构是一个巨大的折衷。 试图在纠结的爱恨关系网中找到最糟糕的解决方案。
Anyone involved in the architecture of software systems has to understand these relationships and their implications. If you ignore one of these relationships your architecture will have a blind spot. If you don’t think about the business model you’ll optimise for the wrong business model. If you don’t think deeply enough about the organisation you’ll have teams fighting an architecture.
参与软件系统体系结构的任何人都必须了解这些关系及其含义。 如果您忽略这些关系之一，那么您的体系结构将是一个盲点。 如果您不考虑业务模型，则会针对错误的业务模型进行优化。 如果您对组织没有足够的思考，那么您将拥有与架构抗争的团队。
Architecture is rewarding because of these complicated relationships. There is always an infinite list of interdependencies and implications to consider. Can you think of any more? Comments welcome.
由于这些复杂的关系，体系结构是有回报的。 总是有无限的相互依存和需要考虑的清单。 您还能想到更多吗？ 欢迎发表评论。
翻译自: https://medium.com/nick-tune-tech-strategy-blog/the-relationship-between-software-architecture-and-business-models-and-more-7209dc3be83e
硬件体系结构模型