Are your microservices too small? Too tightly coupled? This design guide can help.
Web Components are the central concept of Micro Frontends: a ne...
For further actions, you may consider blocking this person and/or reporting abuse
Great article. Small nit:
DDD
I don't believe that is its purpose. But it does encourage drawing proper boundaries around functionality, which resonates with the microservice deployment strategy.
There is problem I see in these characteristics and that's legacy systems. The ideas are great if you're starting from a green field in a startup but, in many cases in the corporate world you'll have a lot of legacy data sources that your microservices will need to work with. Even worse, if you aren't careful, legacy applications may provide a different "truth" than your service.
Often it isn't possible for budget or political reasons to create entirely new databases for microservices. An approach to this that I've used with a legacy Oracle backend is to create packages and schemas that match the service. They still access the same legacy data but the services aren't directly bound to legacy sources. When/If data changes happen, you can make your changes at the database level and your services and front ends shouldn't need to change. You can take a similar approach with other database systems although Oracle seems to make it the easiest to do it from what I've seen.
As for legacy apps, they can be difficult to sunset. So, for a while, you're likely to have two sets of the "truth" circulating. One of the key tests here is to make sure that the legacy and the new services/apps are in sync with each other. If you can switch over the legacy data access to the new service that's great but sometimes that can be more trouble than it's worth (For example, trying to get a poorly written VB6 app to work with a web service for its data.)