3

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.

Community
  • 1
  • 1
drizzie
  • 3,351
  • 2
  • 27
  • 32
  • Voting to close: Too Broad / Primarily Opinion Based – CollinD Feb 09 '16 at 02:48
  • @drizzen are you considering the first approach as a given and wondering whether the *front ends* should be separate, or still not sure about approach 1 vs approach 2 ? – guillaume31 Feb 09 '16 at 11:20
  • We are trying to decide if we should go with approach one or approach two. With approach one, we would break out our separate bounded contexts into different web apps. In approach two, we would keep the web app as a whole, and break out the bounded contexts at the domain level. Parts of our domain will need to be accessed via different applications (mobile, web, etc). – drizzie Feb 09 '16 at 14:02

1 Answers1

1

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

guillaume31
  • 13,738
  • 1
  • 32
  • 51