应用和系统架构代表了如何集成应用并识别使能和支持业务流程执行的业务系统的模型。
AA原则1：应用与领域模型一致
- 声明：不管是定制还是购买，应用都是跨职能域团队创建的领域模型的产品，并受其影响。
- 理由：在制定有效和灵活的解决方案决策时，应同时代表技术和商业利益。
- 含义：
- 领域驱动的设计将用于架构和构建符合业务需求的应用。
- 架构设计先于应用设计和开发。
AA原则2：每个域模型代表一个独立的业务上下文
- 声明：独立的上下文必然会保持独立性
- 原理：有界上下文通过将它们分成单独的概念模块，提供了一种管理大型应用程序复杂性的方法。
- 含义：
- 每个有界上下文都可以自由选择其内部概念的名称，并且具有对其自己的持久性存储的独占访问权。
- 应用程序不共享数据库。
- 有界上下文与组件紧密映射。
- 有界上下文的模型必须在内部是自洽的，但必须独立于其他上下文中的其他模型。
- 每个有界上下文都在API介导的服务中实现并通过其访问。上下文之间的通信通过这些API进行。
AA原则3：实现受限业务上下文的组件通过已发布的公共接口和契约进行通信
- 声明：组件不共享数据，除非通过API。
- 理由：API提供了独立域进行通信和合作的方式。
- 含义：
- 组件是独立的，并针对特定的业务上下文而构建。
- 组件不通过共享数据库共享数据。
- 根据组件的需求，公共接口可能是RESTful，事件驱动，基于消息的，基于凭证或声明的API。
- 组件必须努力保护其内部数据模型与其他组件的一致性。
- 当组件在需要的地方谈论组件之间的组件时，为了提高灵活性和易理解性，首选使用诸如大学API这样的交换语言。
AA原则4：购买和开源解决方案优于自定义解决方案
- 声明：只有在考虑其他来源和第三方替代方案的分析之后，才能做出构建自定义应用程序的决定。
- 理由：在不考虑替代方案的情况下做出的决定可能是昂贵且难以支持的。没有理由重新发明已经存在的东西。
- 含义：
- 项目团队，架构师和系统工程师将在开发新技术之前考虑现有技术。
- 还将考虑分析行业领先的第三方解决方案。
- 在可能和可行的情况下，考虑“订购”而不是购买。
- 总拥有成本应该是任何分析的一部分。
- 购买或建造的决定应考虑上下文是大学使命的核心，支持大学使命还是通用。核心环境更有可能具有独特的业务价值并从定制解决方案中受益。
AA原则5：构建支持连续集成/连续交付方法的应用程序
- 声明：持续交付支持安全，快速且可持续地将新功能，配置更改，错误修复以及实验投入生产或投入用户手中。
- 基本原理：部署应该是常规且可预测的，以降低风险，降低成本并加快上市速度。
- 含义：
- 我们将购买、开发和使用工具来支持系统，配置和错误修复的部署。
- 所有代码都将具有集成测试。
- 监视系统将检测故障，并在必要时自动回滚部署。
- 系统没有有限的更改窗口。这并不意味着产品或领域团队可能不会出于业务原因决定限制更改。
