但是，其他边界上下文（如Orders）不能看到这些实现细节。虽然领域可以为了协调的目的互相发送消息，但是任何一个领域都不能穿透另一个领域的边界上下文。因此，在一个边界上下文中的开发人员可以自由地更改实现，而不必担心破坏其他领域。

　　微服务中的容器是领域驱动设计（DDD）中边界上下文的物理表现：每个容器代表了一层封装，以防止实现细节干扰系统的其他部分。边界上下文提供的隔离展示了结构化软件架构的不同方式。

　　在过去，设计架构主要围绕技术架构：架构模式、库、框架等。例如，分层架构在许多组织中是很常见的：

　　[图1]传统的分层架构

　　在图1中，架构师沿技术层进行分离，使之在需要时可以很容易地替换一整层的内容。例如，如果开发人员需要更改持久机制，所有相关代码都会出现在持久层中。

　　那么开发人员多久更换一次整个持久层呢？几乎从不。但你的团队多长时间基于像Customer这样的概念工作呢？每天！

　　在图1分层架构中，Customer处于哪一层呢？其中部分在表示层、业务层、持久层等等。因此，项目架构上通用单元的变化在分层架构中并没有得到很好的支持，原因是通用的变更影响到了每一层。

　　如果不同层代表了开发团队的不同部分，其影响会更严重。例如，对Customer的更改可能涉及到用户界面、业务逻辑、持久层和其他特性。如果你的组织由开发人员、DBA、用户界面设计师和运维人员组成，而他们在相互隔离的HR部门下，那么进行常见更改的协调成本是巨大的。

　　微服务强调解耦和容器化，翻转了图1中的传统做法，使领域成为架构的主要元素，如图2所示。

　　图2：以领域为中心的架构

　　在图2中，分层结构仍然存在，但是其耦合边界是领域的边界，它将技术架构归入实现细节，并用领域对其进行封装。以技术为中心的组织单元中，员工与员工彼此隔离，要想在这样的组织中构建以领域为中心的架构是很难的。

　　许多技术人员在构建数字化企业中会遇到这样的问题：想要支持如移动应用等新举措，却被那些需要拆分的遗留系统所拖累。如今，这些企业越来越多地引入微服务作为这种拆分过程的关键战略。

　　Greenfield项目得益于DDD实践。通过DDD理解了他们的问题领域以及重要组件之间的接口所在。对于现有项目，更加模块化的系统会促使开发者解开事务性的泥球，并且可以在那些属于一起的组件和偶然耦合的组件之间做更清楚地区分。

　　团队

　　你还将遇到微服务对团队影响：一个架构风格是如何推动开发团队重组的。

　　1968年，梅尔文·康威对软件开发做了一个很有预见性的观察，被称为：

　　设计系统的组织，其产生的设计等价于这些组织间的沟通结构。

　　康威定律对软件开发的意义是什么呢？你的设计反映了你的团队结构。企业常见的团队结构是由人力资源部门推动的，他们将职能类似的技术专家组织在一起。虽然这是一种符合逻辑的排序算法，但这种结构在设计自包含服务时效果不佳。

　　如我们认为的康威逆定律，现在许多公司在围绕业务领域组织跨职能团队，而不是围绕技术分层构建。例如，一个Customer服务可能包括一个业务分析师、开发人员、QA、UX、DBA和运维人员。

　　团队会在准备好之后再部署服务，而不是先构建一些东西传递到运维人员，使之包含在下一个巨大的发布中。许多选择微服务的公司使用持续部署，以尽快将变更投入生产环境中。

　　总结

　　企业高管可能会认为微服务是最新流行词而不予考虑，但那些了解这种架构影响的人可以获得实实在在的好处。微服务可以提高交付速度，增强灵活性，并提高效率。他们将工作进行重组，并与业务问题域保持一致，而不是技术域；从一组独立，更易于开发和维护的服务中创建业务应用程序；更好地匹配技术解决方案与业务问题的复杂程度；构建可以帮助重组现有遗留系统以及创建能够快速响应不断变化的业务条件的新产品和服务的自适应架构。