领域驱动设计的笔记(6)

>我来写笔记

按有用程度 按页码先后 最新笔记

  • zhji

    zhji

    软件开发复杂的根源是问题领域本身的错综复杂。 领域建模的过程不应该将概念与实现割裂开来, 原因在与领域模型的最大价值就是它提供了一种通用语言, 而通用语言是将领域专家与技术人员联系在一起的纽带。 领域模型,并不是按照“先建模,后实现”这个次序来工作的。作者经验是,真正强大的领域模型是随着时间演进的,即使是最有经验的建模人员也往往发现他们是在系统初始版本完成之后才有了最好的想法。 --Martin Fowler

    2018-04-04 15:49

  • romain

    romain

    mark

    2013-02-21 19:08

  • Leechael

    Leechael (槲寄生一株)

    当子系统必须与大量的其他系统集成时,为每个系统定制一个转换器可能会让团队陷入困境。转换器越多,那么在作出改变时,需要担心的事情也越多。 定义一个协议,把你的子系统作为一组服务来使用。开放这个协议,让所有需要与您集成的人都能使用该协议。除非当一个团队有特殊需要时,否则,应该改进和扩充协议来满足新的集成需求。而为那种特殊情况使用一次性转换器来扩充该协议,从而可以保持公用协议的简单性和一致性。

    2012-06-08 13:52

  • Leechael

    Leechael (槲寄生一株)

    声明一个与其他上下文根本没有任何连接的限界上下文,让开发人员在这个小范围内找出简单、专门的解决方案。 这种特性仍然可以组织在中间件或者 UI 层中,但是不存在逻辑共享,并且通过转换层的数据传输绝对最少,甚至没有。

    2012-06-08 04:32

  • Leechael

    Leechael (槲寄生一株)

    根据两个领域模型创建一个隔离层,为客户提供功能。该层可以通过现有接口与另外一个系统会话,而无需修改那个系统。在内部,该层进行两个模型之间必要的双向转换。 我怎么想起了 Protocol Buffers…   (1回应)

    2012-06-06 12:54

  • Leechael

    Leechael (槲寄生一株)

    如果正在创建的新系统与其他系统必须依靠一个大型的接口来连接,那么关联两个模型的难度可能最终会推翻新模型打算表现的意图,而是以一种特别的风格被修改成类似于另外那个系统的模型。老式系统的模型通常很弱,即使是精心开发的例外,也可能会不适合当前项目的需要。然而在集成中可能会有许多有价值的东西,而且有时候是绝对需要集成的。

    2012-06-06 12:49

笔记是你写在书页留白边上的内容;是你阅读中的批注、摘抄及随感。

笔记必须是自己所写,不欢迎转载。摘抄原文的部分应该进行特殊标明。

领域驱动设计

>领域驱动设计