Gain insights into implementing practical software architectures, mastering key development methodologies, and distinguishing core principles, ensuring your skills remain relevant in the ever-evolving industry.

Effective Software Development for Enterprise Applications.png

Non-readable code? Non-practical architectures? Unclear requirements? Are you pulling your hair at this point?

These are exactly the sort of pitfalls this course serves to provide in-depth remediation for. Over your years of working in the software industry, numerous day-to-day challenges like these come and go. While the industry has been constantly transforming, some core principles and values remain amidst the advancing technologies. 

Through tried and tested approaches, you will learn how to practically implement 'Effective Software'. With a comprehensive compilation of key concepts in software development methodology, you will be left with essential techniques for becoming a better software craftsman. It is time to distinguish between the core and the noise, making your skills timeless!

Effective Software Development for Enterprise Applications

As I mentioned earlier, microservices are an evolution of #key# SOA: Service-Oriented Architecture #key#. SOA services enabled structuring entire enterprises around them. Similarly, microservices can evolve into a connected ecosystem within or across organizations. Therefore, it is utterly essential to know the basic principles of building microservices. I recommend that you check out resources online that teach the concept of microservices and related patterns (e.g., see [here](https://microservices.io/)).

In this section, I want to cover a couple of vital aspects for building and evolving an ecosystem of microservices. Specifically, how should we build UI in front of existing services? Do we go with [**Monolithic UI**](https://docs.microsoft.com/en-us/dotnet/architecture/microservices/architect-microservice-container-applications/microservice-based-composite-ui-shape-layout), [**Client-Side UI composition,**](https://microservices.io/patterns/ui/client-side-ui-composition.html) or [**Server-Side Page Fragment Composition**](https://microservices.io/patterns/ui/server-side-page-fragment-composition.html)? Since each of these approaches is valid in certain cases, I want to discuss them in more detail by covering their implementation intricacies.

[*Monolithic UI*](https://docs.microsoft.com/en-us/dotnet/architecture/microservices/architect-microservice-container-applications/microservice-based-composite-ui-shape-layout) is the most straightforward approach for teams that build microservices. However, from an architecture standpoint, I would recommend staying away from this pattern whenever possible. Here is my reasoning behind my precaution; you will incur a communication and integration overhead between a team that builds Monolithic UI and all other groups who create backing microservices. You have a single point of failure and a bottleneck in the face of the UI team. While you may smooth out integration overhead, conflict of interests will always get in your way; the UI team tries to build the optimal user experience. In contrast, backend services teams want to implement technically optimal API endpoints. Although the combination of these two objectives sounds like an ideal solution, underlying driving forces pull implementations into different directions, making it difficult to integrate or deliver optimal solutions.

For example, a backend microservice team might decide that they will return a complete dataset, and UI could do necessary sorting, filtering, and paging afterward. This technique makes sense if we look at API development in isolation; the resulting endpoint would be highly reusable for all kinds of consumers. Now, look at the situation from the UI team’s standpoint; they want to make the user experience as lightweight as possible without fetching a single unnecessary data bit. Querying a complete dataset and then narrowing it down in the browser goes against the objective of the optimal user experience. Additional data sitting in the browser’s memory might jeopardize the goal. In this conflict of interests, one or the other side needs to compromise.

I do not doubt the feasibility of a compromise. Instead, I am worried that the arrangement will be based on secondary factors, such as the relationship between teams instead of more vital aspects, e.g., the effectiveness of user experience. Therefore, when possible, avoid following a Monolithic UI pattern to avert adverse effects on customer satisfaction.

Learn how to build and evolve an ecosystem of microservices.

Fundamentals

Part I: Introduction

Part II: Crosscutting Concerns

Part III: From Customer Insights to Internal Requirements

Part IV: Design and Architecture

Part V: Implementation and Coding

Part VI: Testing and Quality Assurance

Part VII: Deployment

Part VIII: Maintenance and Support

Wrap-Up

Ecosystem of Microservices