读《领域驱动设计模式、原理与实践》

美国，Scott Millett, Nick Tune

代码示例用的是 C#

我 喜欢本书的原理部分就是前部分。

不喜欢的点是：

• 纸太溥了，南方潮不好翻，这下更不好翻了。
• 书的油味太不好闻了。超级不好。味还大。
• 做为新书还用上下文这样的翻译，认为不好。

创建和维护软件的难处。

BBoM 是一大片随意构造、杂乱无章、凌乱、任意拼贴、毫无头绪的代码丛林。（大泥球，Big Ball of Mud）

领域复杂性和技术复杂性混合在了一起。的结果。

缺乏应有的关注和考量。

需要持续致力于知识的提炼，以生成可以在数年而不仅仅是数月中可维护的软件。

询问领域专家当前系统的哪些部分难以使用。

CRC卡：类名称；类的职责；与满足其目的相关且所需的类。

介绍常见模形的书《Analysis Partterns: Reusable Object Models》 Martin Fowler 著

并非一个系统的所有部分都需要良好的设计

与领域专家一起创建一份领域术语表

实际上，不应期望对真实情况完整建模，而是对问题域中有用的抽象概念建模。要寻找问题域中的共通性和变化。

尝试在单个模型中创建所有内容往好处说是鲁莽，往最坏的极端说就是浪费时间且毫无意义。

要根据系统中的不变条件和规则来定义联系。

没有领域逻辑时不要浪费时间做设计，直接干活。

团队结构和工作地点也能对领域开发结果的边界造成很大的影响。

规模并非是描绘边界的准则。

监控错误

重新尝试处理的情况

消息传递框架会停止重新尝试处理有害消息，放入错误队列的特殊队列中。

函数编程：资料：https://www.haskell.org/haskellwiki/Functional_programming

推荐 4 星

虽然本书有各种不喜，但一本书带给我新鲜的东西那怕只有一点点也是值得的，这就是我去读各种书的目地。

领域这个概念也许我和作者理解的不一样，但是我觉得我理解的东西，可以用到我的知识框架中来补充一些我不知道的。

欣喜。