如何一步一步用DDD设计一个电商网站（一）

    ①合作关系（Partnership）：如果2个限界上下文的团队要么一起成功，要么一起失败，此时就是这种关系。应该为相互关联的软件功能制定好计划表，这样可以确保这些功能在同一个发布中完成。

    ②共享内核（Shared Kernel）：对模型和代码的共享将产生一种紧密的依赖性，对于设计来说，这种依赖性可好可坏。我们需要为共享的部分模型指定一个显式边界，并保持共享内核的小型化。共享内核具有特殊的状态，在没有与另一个团队协商的情况下，这种状态是不能改变的。我们应该引入一种持续集成过程来保证共享内核与通用语言的一致性。【简单的说就是数据库共享】

    ③客户方——供应方（Customer-Supplier Development）：当2个团队处于一种上游——下游关系时，上游团队可能独立于下游团队完成开发，此时下游团队的开发可能会受到很大的影响。因此，在上游团队的计划中，我们应该顾及到下游团队的需求。

    ④遵奉者（Conformist）：在存在上游——下游关系的2个团队中，如果上游团队已经没有动力提供下游团队之需，下游团队便孤军无助了。处于利他主义，上游团队可能向下游团队做出种种承诺，但是有很大的可能是：这些承诺是无法实现的。下游团队只能盲目地使用上游团队模型。

    ⑤防腐层（Anticorruption Layer）：在集成2个设计良好的限界上下文时，翻译层可能很简单，甚至可以很优雅的实现。但是，当共享内核，合作关系或客户方——供应方关系无法顺利实现时，此时的翻译将变得复杂。对于下游客户来说，你需要根据自己的领域模型创建一个单独的层，该层作为上游系统的委派向你的系统提供功能。防腐层通过已有的接口与其他系统交互，而其他系统只需要做很小的修改，甚至无需修改。在防腐层内部，它在你自己的模型和他方模型之间进行翻译转换。【为每个防腐层定义相应的领域服务】

    ⑥开放主机服务（Open Host Service）：定义一种协议，让你的子系统通过该协议来访问你的服务。并且需要将协议公开。

    ⑦发布语言（Published Language）：在2个限界上下文之间翻译模型需要一种公用的语言。此时你应该使用一种发布出来的共享语言来完成集成交流。发布语言通常与开放主机服务一起使用。

    ⑧另谋他路（SeparateWay）：在确定需求时，我们应该做到坚持彻底。如果2套功能没有显著的关系，那么它们是可以被完全解耦的。集成总是昂贵的，有时带给你的好处也不大。声明2个限界上下文之间不存在任何关系，这样使得开发者去另外寻找简单的、专门的方法来解决问题。

    ⑨大泥球（Big Ball of Mud）：当我们检查已有系统时，经常会发现系统中存在混杂在一起的模型，它们之间的边界是非常模糊的。此时你应该为整个系统绘制一个边界，然后将其归纳在大泥球范围之列。在这个边界内，不要试图使用复杂的建模手段来化解问题。同时，这样的系统有可能会向其他系统蔓延，应该对此保持警觉。    

本文由网络公关公司鹏程天行科技网络收集整编，均不代表本站任何观点，成都危机公关公司,专注于政府公关,企业公关媒体传播,品牌维护,品牌网络传播,负面信息处理等方面的全方位、专业化服务的公关公司,欢迎联系

• 上一篇：旺店通ERP旗舰版，ERP+WMS整体电商解决方案
• 下一篇：企业网络营销运营关键点合格团队需要什么

TAG标签: 　　 一步 　 　　 如何 　 　　 设计 　 　　 一个