维度建模 范式建模
域驱动设计 （DDD）提倡对域进行建模并以代码形式表示此模型，这是成功交付和持续维护软件的基础。 我完全同意这一点。 我们多久看到一次与问题域近似的代码？ 表现出行为的代码接近通过适当的不适当的抽象和映射所需要的行为。 代码中的内容和实际域之间的那些映射仅包含在开发人员的头脑中，这还不够好。
当需要高性能时，系统各部分的代码通常必须对CPU，内存，存储子系统或网络子系统的情况进行建模。 当我们在这些域上有不完善的抽象时，性能可能会受到非常不利的影响。 我的“ 机械同情 ”博客的目的是窥探引擎盖下的内容，以便我们改进抽象。
什么是模型？
模型不必是3年生产UML的结果。 人们可以通过语音，绘画，插图，隐喻，类比等各种方式进行交流，以建立共同理解的心理模型，并且通常是最好的。 如果能够获得准确而精炼的理解，那么可以将此模型转换为具有出色结果的代码。
基础架构领域模型
如果编写并发框架的开发人员没有一个典型的缓存子系统如何工作的良好模型，即它使用消息传递来交换缓存行，则该框架不太可能表现良好或正确。 如果他们的代码以机械的同情和理解来驱动高速缓存子系统，那么它很少会出现错误，并且更有可能表现良好。
通过了解基础平台的基础结构及其发布的功能，从声音模型预测性能要容易得多。 例如，如果您知道一个网络子系统每秒可以处理多少个数据包，以及其传输单元的大小，那么很容易推断出预期的带宽。 有了基于模型的理解，我们可以放心地测试我们的代码对期望的期望。
我已经解决了许多性能问题，即当框架实际上是基于块的模型时，框架会将存储子系统视为基于流的。 如果更新磁盘上文件的一部分，则必须读取要更新的块，应用更改并回写结果。 现在，如果您知道系统是基于块的，并且知道块的边界，则可以写回整个块，而无需进行读取，修改，写回循环，只需一次写入即可替换这些操作。 即使在附加到文件时也是如此，因为最后一块可能先前已被部分写入。
业务领域模型
我们为业务领域构建的模型应采用相同的思路。 如果业务流程的建模准确，那么该软件将不会令其最终用户感到惊讶。 绘制模型时，重要的是描述基数的关系以及遍历它们的特征。 这种理解将指导选择最适合实现关系的数据结构。 我经常看到人们使用一个关系列表，而该关系列表大多是按关键字搜索的，在这种情况下，地图可能更合适。 关系另一端的实体是否排序？ 树或跳过列表实现可能是更好的选择。
身分识别
模型中实体的身份是如此重要。 必须以某种方式输入所有模型，这通常从要行走的实体开始。 该实体可以通过客户ID称为“客户”，但也可以通过文件名和在基础结构域中的偏移量等效为“ DiskBlock”。 系统中每个实体的身份必须清楚，以便可以有效地访问模型。 如果对于模型的每次交互，我们都浪费了宝贵的时间来尝试寻找实体作为起点，那么其他优化几乎就变得无关紧要了。 使身份在模型中明确显示，并在必要时根据其身份对实体进行索引，以便您可以为每次交互有效地输入模型。
在学习时不断完善
在学习过程中不断完善模型也很重要。 如果模型不经过提炼和蒸馏而扩展为一系列扩展，那么我们最终将面临意粉混乱，在试图实现可预测的性能时很难管理。 没关系，维护和支持有多困难。 我们每天都在学习新事物。 在模型中反映出来并保持最新。
实施所需的东西不多，但也要少！
最快的代码是仅执行所需功能的代码，仅此而已。 执行说明即可完成任务，仅此而已。 真正快速的代码通常不是一堆奇怪的移位和编译器技巧。 最好从干净优雅的东西开始。 然后进行测量以查看您是否在性能目标之内。 因此，这通常就足够了。 有时性能会令人惊讶。 然后，您需要先运用科学进行测试和衡量，然后才能得出结论。 探查器通常会告诉您时间在哪里。 一旦纠正了基本的建模错误和假设，通常只需一点机械上的同情就可以达到性能目标。 未使用的代码是浪费。 尝试不创建它。 如果您碰巧要创建一些代码，请在发现代码后立即将其从代码库中删除。
结论
当非功能性需求（例如性能和可用性）对于成功至关重要时，我发现最重要的事情是使模型在各个级别的领域都正确无误。 也就是说，采用DDD的原理，并确保您的代码是每个域的适当反映。 无论是业务应用程序领域还是与基础架构交互的领域，我都发现建模就是一切。
翻译自: https://www.javacodegeeks.com/2012/08/modelling-is-everything.html
维度建模 范式建模
4013
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
