架构师资料教程

本文讨论可组合应用程序架构的概念和架构模式。 在一个组织中进行软件选择的基本假设已经发生了变化。虽然原则、政策和指导方针是相同的，但在大多数情况下，以下因素对产品、技术和开发的选择有直接影响。 一个组织内现有的技能 所选技能

近年来，我在IT公司遇到过很多因软件架构不正确而导致的问题。 不正确是什么意思？ 在大多数情况下，这是一个方向——相对于它应该解决的问题来说：要么过于简单要么极其复杂</

使用架构思维解决以客户为中心的商业问题的创新技术（设计+行政管理）。 架构方面，我们是如何处理？并将设计思维嵌入到这个过程中： 初步阶段：界定企业的范围 界定并建立一个针对组织的EA框架

在21世纪初，许多网络公司意识到DBA并不了解新公司的需求，因此 "阻碍 "了 "快速发展和突破 "的进程。因此，他们开始避开RDBMS和/或DBA，在应用程序代码中重新创造许多功能。RDBMS开始仅仅被用作 "哑巴存储"，其他功能被转移到应用程序代码中。

年收入 20 亿美元的规模才有充分理由采用微服务架构，其他规模则可采用：单体式架构演化为基于服务的模块化单体式架构，然后演化为宏服务、迷你服务、微服务。 什么是微服务架构？微服务架构就像沙漠中的一粒

可视化您的软件架构的最佳免费和付费工具： 软件架构工具可以分为三类：建模工具、图表即代码和图表工具。 作为代码工具的建模和图表更适合长期文档，而图表工具更适合快速绘制一次性草图。 作为代码的建模和图表具有更多结构并且需要更多设置，而图表工具更通用但需要更少思考

是否有合适的免费工具来有效实施企业架构 (EA)？这是我们根据 2022 年的综合测试得出的前 5 名排名。 在AI领域，我们看到了OpenAI的ChatGPT等自由颠覆者的出现，它正在渗透市场，颠覆市场，颠覆软件工程、文本制作、预见、艺术等众多领

Rust借用检查器缺点：不适合原型设计和快速迭代当你从事系统设计/架构时，Rust 的复杂性经常会使事情变慢，而当你在一个可靠的设计中实现一些确定的部分时，它通常会使事情变得更快（但如果它不可靠，它可能只会让你感到厌烦完全停止）。

软件架构文档创造了共同的理解（在同一种语境上下文BC中的达成共识） 软件架构文档至少应该支持开发团队，例如，当一个

关于软件开发，可扩展性这个词的两个最常见的含义与代码库的性能和长期可维护性有关。你可以同时拥有这两点，但专注于良好的可维护性会使你更容易调整性能而不影响应用程序的其他部分。在前台更是如此，在这里我们有一个与后台的重要区别：本地状态。 在这一系列的文

有四种类型的检查表，在任何工作开始之前，我们需要将它们全部到位。 第一种类型的检查表是行动检查表action-checklist：一种工作指令，它是一个任务清单，按顺序，一步一步，用于 "已知-已知"，当我

EA 成熟度演进可描述为三个阶段。每个阶段都有特定的 EA 资源、独特的重点和独特的产品组合，EA 领导者可以通过这些资源查看组织的架构。所有成熟度级别都有望实现适应性、创造性和弹性架构。 第一阶段：技术架构的兴起。在此阶段，组织认识到他们的技术成本高昂、复杂且不适应。这反过

架构师是否必须编码，已经有了很多争论。为什么不尝试调试？ 架构师喜欢做错事架构师必须定期测试他们的假设，如果他们发现其中一些假设是错误的，他们必须感到高兴--这就是我们保持相关性的方法。

讨论分离业务和技术代码的好处，并解决常见的误解。 “域”是“业务域”的缩写。在这里，业务在广义上指的是应用程序旨在解决的现实问题（例如，待办事项列表、在线商店或游戏）。

我与Nick Tune共同撰写了这篇文章（

CUPID 的五个属性是： Composable可组合：与其他人一起玩得很好 Unix哲学：做好一件事 Predictable可预测的：做你期望的 <