在决定使用 DDD 将我们的整体 Web 应用程序拆分为单独的 Web 应用程序时，我应该考虑什么? [英] What should I consider when deciding to split our monolithic web application into separate web apps using DDD?

问题描述

背景

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

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

来自这篇 SO 帖子，有两种方法可以实现有界上下文.

|_ 域|_ 申请|_ 介绍|_ 基础设施<bc 2>|_ 域|_ 申请|_ 介绍|_ 基础设施

或以下内容:

域|_ <bc 1>|_ <bc 2>应用介绍基础设施

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

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

我们的应用程序有几个(为简洁起见)主要领域:

产品客户管理系统管理

当用户处于特定区域时，他/她通常几乎不需要其他区域的信息.

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

解决方案

微服务的基本基础之一是 独立可部署性，所以我肯定会采用方法 1.

现在在这种情况下，微服务的呈现层"并没有像前端 UI 那样深入，它通常只是一个 REST API.有多种设计使用微服务的前端的方法，但是如果 Product、Client 和 System 前端具有不同的生命周期，我会推荐为他们提供单独的网络应用程序.

关于该主题的有用文章:http://blog.xebia.com/the-monolithic-微服务架构中的前端/http://samnewman.io/patterns/architectural/bff/#bff>

Background

We use the Microsoft (.NET) technology stack.

We currently have a large monolithic web app. We are planning how to implement Domain Driven Design.
We plan to implement microservices on some bounded contexts, but not all. Because it is a monolith, most bounded contexts will live in the same database, so we'll have to make sure that we control access at the code level.

From this SO post, there are two ways to implement bounded contexts.

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

or the following:

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

We are interested in the first approach. because it seems like it would fit our situation.

My question is, what should we consider when deciding if we should split our single web application into separate applications by bounded conexts. What are some of the drawbacks and gotchas when considering this approach?

There are a few (for brevity) main areas of our application:

Products
Client Administration
System Administration

When a user is in a particular area, he/she usually needs little information about the other areas.

All thoughts and recommendations are welcome. We are trying to gain as much understanding as possible.

解决方案

One of the basic underpinnings of microservices is independent deployability, so I would definitely go with approach 1.

Now in that scenario, the "Presentation layer" of a microservice doesn't go as far as the front-end UI, it's usually just a REST API. There are several approaches to designing front ends that consume micro services, but if the Product, Client and System front ends have different lifecycles I would recommend having separate web applications for them.

Useful articles on that subject : http://blog.xebia.com/the-monolithic-frontend-in-the-microservices-architecture/ http://samnewman.io/patterns/architectural/bff/#bff

这篇关于在决定使用 DDD 将我们的整体 Web 应用程序拆分为单独的 Web 应用程序时，我应该考虑什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！