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