领域驱动设计：软件核心复杂性应对之道
设计领域模型，便于跟专业人士沟通，设计的系统也更加精准，更贴近实际。
画图有益于理解，简单的图易于一起讨论。但是有一些代码表示不清楚的可以写文档，益于长久。
设计人员应参与代码的实现，至少要了解。 否则设计与实现不同，问题很大。
分层中 （界面层-> 应用层 -> 模型层 -> 基础设施层）， 业务规则应存在模型层。
调用应使用抽象，如A需要B某个功能呢，那么B提供一个抽象的接口即可，不需要暴露内部实现。
SMART UI -> 将业务规则封装到UI组件中。 (优点：快，易，缺点: 模块重用性差)
各个模型应该明确职责与关系，以便维护。 切勿过度设计而导致开发工作加重。
entity: 具有唯一标识且不会改变的对象。 (如 city, country)
value-object: 会随主体变化而变化的对象。(如 router)
service: 对实体模型的业务操作。
module: 每个细分领域的都可以看成一个module, 每个module之间是高内聚低耦合的。
模型的定义要清晰，不要轻易妥协与其他对象职责耦合。 对象设计时候可以包含抽象，这样可以便于以后的扩展。
ubiquitous-language: 无处不在的语言，意思为 常识
Last updated