限定上下文BC

Richard Clayton分享了自己在微服务实践中的失败经历，避免更多人犯同样的错误。这些问题主要有以下几点： 1.开发人员之间的哲学观点的差异我们团队对微服务分为以下三个派别:a.喜爱微服

你的微服务是否太小？或者太紧密耦合？本设计指南可以提供帮助。 设计微服务往往更像是一门艺术而不是科学。本文提出五个建议： 1.它不会与其他服务共享数据库表2.它拥有最少量的数据库表3.它设计为有状

清晰架构Clean Architecture，又称干净架构、清晰架构、整洁架构、清洁架构，是著名软件工程大师Robert C Martin提出的一种

这是来自《POJOs In Action》作者和CloudFoundry原创始人Chris Richardson的一篇谈论微服务PPT，结合DDD和事件驱动，比较全面和可落地。大意翻译如下： 以一个在线商店为案

请banq大牛帮助解答一下疑问吧，谢谢最近结合着《Java Modeling in Color with UML(四色原型)中文版》看《实现领域驱动设计》，感觉四色原型里提供的组件并未按照领域驱动设计的思想去做。我把四色原型中的物料资源管理中有好几个组件，我

以前的设计思路就是，通过画出usecase之后 找出需要被存储的表和属性，然后在业务操作的时候就是操作对应的表数据，这样典型的就是数据库驱动设计。如果碰到复杂的业务系统，数据库设计就会让人望而生畏，没有标准的设计原语，只有生涩的数据库图表，一旦复杂系统升级基本上是噩梦不如重做。

微服务是通过否定单体巨石monolithic而诞生的，单体巨石意思是铁板一块，高度耦合在一起，如同搅拌在一起的意大利面，或者说拌面，代码之间纠缠不清，修改维护难度很大，难以增加新功能，而微服务是根据业务领域中自然形成的聚合进行切分，也就是说，微服务不是对单体随意一刀切进行分割，而是根据有界上下文，在

在这篇文章中，作者讨论了他最近学到的关于从不同的角度识别微服务边界的一个教训。 微服务架构是当今的热门话题。 尽管它的复杂性（分布式事务，最终的一致性，操作开销），这些都是不可避免的，但是它提供了许多好处（多边形架构，选择性可扩展性，强模块化，容错，实验

Cribbb是一个使用DDD聚合根和领域事件Domain Events概念开发的PHP开源通知框架：cribbb/cribbb · GitHub

论坛当然可以当作一个上下文，但个人感觉 图片 ／视频 等媒体资源，这应该是另一个上下文。个人感觉。 论坛主要是交流的（论坛），而媒体资源应该在另一个上下文中（媒体管理） 然后，身份验证是另一个上下文。 <

“ 一个微服务应该涵盖一个有界的上下文 ” Vaughn Vernon断言。它引发了与

项目需求得到如下上下文 ： 媒体管理 ／ 论坛 ／ 电子书 这3个都需要用户权限管理，这时候当然最好的是有个rbac系统，但单独开发它很耗时，我就采用了共享内核。这个内核就是 user ，很小，只有一个user aggre

A Bounded Context does not necessarily encompass only the domain model. True, the model is theprimary occupant of the conceptual container. Howeve

复制比错误的抽象便宜得多（代价小成本低），宁可重复而不选择错误的抽象。让人们意识到“错误的抽象”这个问题是很难： 程序员A看到重复。 程序员A提取重复并为其命名。这创建了一个新的抽象。它可能是一种新方法，甚至可能是一种新类。 程序员A用新的抽象

Identity用户验证模块 和 论坛模块 是两个上下文 ，通过 identity可以继承各种模块定制个性系统。 论坛独立模块分离完成。 架构如下： Identity用

“ 不要重复自己 DRY”，每个开发者都在他职业生涯的早期就学会了这个口头禅。对这个原则的共同理解是你不应该复制你的代码。就那么简单。不要复制，如果你发现重复就重构。违反此规则的行为将被其他开发人员立即指出为侵犯软件开发最基本的做法之一。