您试图混合使用 Solution Architecture 和 Enterprise Architecture，这可能就是它看起来令人困惑的原因。
TOGAF 是关于企业架构的——正如您正确指出的那样。另一方面，关于具体应用程序的信息更多是解决方案架构问题。当然，有人可能会争辩说，您可以根据需要尽可能详细地描述企业架构，但这不是重点。
不过，回答您最初的问题：您拥有的应用程序信息（架构描述、组件描述、功能描述）似乎应该存储在Architecture Repository 中，就像Solution Building Blocks 一样。我建议在Phase C 和Phase D 期间将它们作为Baseline Application Architecture 和Baseline Technology Architecture 描述的一部分。
再说一次，你应该首先仔细考虑你是否真的需要这么高的细节水平。
附：如果您提供更多有关您要实现的目标的背景信息，我可能会给您更具体的建议
2018 年 11 月 11 日更新
我可以将公司结构、人员、团队等公司信息放在哪里？
这取决于。公司结构应作为Organization structure 模型的一部分存储在Baseline/Target Business Architecture 中。这是来自 TOGAF 的定义：
“组织结构：记录组织结构，确定业务地点并将其与组织单位相关联。”
它也是输入之一 - Organizational Model for Enterprise Architecture（参见第 IV 部分，TOGAF 规范的 36.2.16）。
我可以将公司提供的产品和服务等业务信息放在哪里，定价是如何计算的？对企业来说，“X 事”是什么意思？
它也是Business Architecture 的一部分，这是来自 TOGAF 规范的完整列表：
- 组织结构 - 确定业务地点并将其与组织单位相关联
- 业务目标和目的 - 针对企业和每个组织单位
- 业务功能 - 一个详细的递归步骤，涉及将主要功能区域连续分解为子功能
- 业务服务 - 企业和每个企业单位向其客户提供的内部和外部服务
- 业务流程，包括措施和可交付成果
- 业务角色，包括技能要求的开发和修改
- 业务数据模型
- 组织与职能的相关性 - 以矩阵报告的形式将业务职能与组织单位相关联
我应该把正在进行的评估放在哪里？投入生产后我应该把它放在哪里？
TOGAF 中有一个标准模式：
- 评估当前情况并将其写为
Baseline Architecture
- 创建一个愿景并将其写为
Target Architecture
- 朝着
Target Architecure 努力，随时更新Baseline Architecture
因此，最终，您的基线应该等于目标，现在它是您下一个 ADM 周期的新基线。
我应该把通用术语表放在哪里？
通常在为您的企业定制 TOGAF 时尽快完成 - ADM 周期的Preliminary Phase（请参阅第 IV 部分，TOGAF 规范的 36.2.21）。
我应该把开发指南放在哪里？比如环境列表、IP、交付工作流程、jira 工作流程等？
开发指南、jira 工作流程和其他项目管理内容通常不是 TOGAF 直接关注的问题。一定要知道，企业架构师甚至可能会就这件事进行咨询。在项目管理方面，只有一件事会浮现在脑海中 - 路线图，它们几乎在所有阶段都被记录下来并根据需要进行更新。
环境、IP 和其他基础设施信息通常在Phase D 期间处理，主要作为技术架构模型和规范的一部分。
我应该将服务 API 定义放在哪里？
同样，您应该仔细考虑是否需要这种详细程度，但在Phase C (Applications Architecture) 中解决它似乎是合适的。其中一个步骤是定义模型（TOGAF 建议在您的行业中找到参考），其中可能包括 API 定义。就企业而言，解决一个更抽象的Applications Interoperability 通常就足够了。
非常重要的一点：TOGAF 只是一个框架，您可以根据自己认为适合当前企业的情况对其进行定制，只是不要忘记记录它。您还应该记住，它不仅是一组工具，而且是一组期望、术语表和指南，因此新架构师不需要在他工作的每个新企业中从头开始学习所有内容。一如既往——你必须找到一个合适的平衡点。