在决定使用 DDD 将我们的单体 Web 应用程序拆分为单独的 Web 应用程序时，我应该考虑什么？ [关闭]答案

【问题标题】：What should I consider when deciding to split our monolithic web application into separate web apps using DDD? [closed]在决定使用 DDD 将我们的单体 Web 应用程序拆分为单独的 Web 应用程序时，我应该考虑什么？ [关闭]
【发布时间】：2016-05-18 21:46:59
【问题描述】：

背景

我们使用 Microsoft (.NET) 技术堆栈。

我们目前有一个大型的单体网络应用程序。我们正在计划如何实施领域驱动设计。
我们计划在一些有限的上下文中实现微服务，但不是全部。因为是单体，大多数有界上下文将存在于同一个数据库中，因此我们必须确保我们控制访问代码级别。

从this SO post 开始，有两种方法可以实现有界上下文。

<bc 1>
 |_ domain
 |_ application
 |_ presentation
 |_ infrastructure
<bc 2>
 |_ domain
 |_ application
 |_ presentation
 |_ infrastructure

或以下：

domain
 |_ <bc 1>
 |_ <bc 2>
application
presentation
infrastructure

我们对第一种方法感兴趣。因为它似乎适合我们的情况。

我的问题是，在决定是否应该通过有界上下文将单个 Web 应用程序拆分为单独的应用程序时，我们应该考虑什么。在考虑这种方法时有哪些缺点和陷阱？ p>

我们的应用程序有几个（为简洁起见）主要领域：

Products
Client Administration
System Administration

当用户在一个特定区域时，他/她通常需要很少的关于其他区域的信息。

欢迎所有想法和建议。我们正在努力获得尽可能多的理解。

【问题讨论】：

投票结束：过于广泛/主要基于意见
@drizzen 您是否认为第一种方法是给定的，并想知道前端是否应该分开，或者仍然不确定方法 1 和方法 2？
我们正在尝试决定是采用方法一还是方法二。使用方法一，我们会将单独的有界上下文分解为不同的 Web 应用程序。在方法二中，我们将 Web 应用程序保持为一个整体，并在域级别打破有界上下文。我们的部分域需要通过不同的应用程序（移动、网络等）访问。

标签： architecture domain-driven-design n-tier-architecture

【解决方案1】：

微服务的基本基础之一是independent deployability，所以我肯定会采用方法 1。

现在，在这种情况下，微服务的“表示层”并没有像前端 UI 那样深入，它通常只是一个 REST API。有几种方法可以设计使用微服务的前端，但如果 Product、Client 和 System 前端具有不同的生命周期，我建议为它们使用单独的 Web 应用程序。

关于该主题的有用文章： http://blog.xebia.com/the-monolithic-frontend-in-the-microservices-architecture/ http://samnewman.io/patterns/architectural/bff/#bff

【讨论】：