# DSC Layered Architecture ![Hero Image - Stack of pancakes](https://hackmd.io/_uploads/S15yAb8Xa.png) ## Introduction Cast your mind back to the days of crafting solutions for the Digital Shop Counter (DSC), the flagship online portal of print-it-for.me. Your expertise had left a mark on the project before you transitioned away. Now, after some years, your mastery is once again in demand. The landscape of DSC has undergone a remarkable evolution. Its user base has grown, with a plethora of small to medium enterprises integrating the platform into their daily workflows. Even the medium-sized customers now routinely submit numerous printing requests within a single business day. In light of this expansion, the DSC has transformed its original design; it is now a highly sophisticated order management and tracking ecosystem, a cornerstone on which our clientele depend with confidence. The data architecture within DSC has witnessed a similar expansion, a testament to its scalability. What once was a customer record with a modest count of fewer than 30 attributes has grown into a complex entity with nearly 200 distinct properties. These records encapsulate a diverse range of associated data, from cost centers and delivery addresses to employee information crucial for access permissions. The same growth rate is mirrored in the structure of order records. To navigate this amount of data, the User Interface (UI) has undergone a significant transformation. In pursuit of optimal user-centric design, the UI now contains a customizable grid view. Through intuitive drag-and-drop interactions, customers can tailor their grids to spotlight the data points most important to their operations. The grids have been augmented with robust search functions, granting users the power to filter the large number of properties at their disposal. This degree of customization and control has been met with enthusiasm from our users. However, with greater power comes greater responsibility — and in this case, a challenge. The enriched functionality and flexibility have inadvertently introduced a latency that users are finding increasingly noticeable. Performance, once a silent guarantee, has now surfaced as a pressing concern that must be addressed to uphold the integrity and efficiency of the DSC experience. ## Today's Architecture ### Layered Architecture The core of DSC's order management has been built using a _Layered Architecture_ approach. Each layer is only allowed to access functionality of the layer _directly_ below it (_closed_ layering approach). ```txt ┌─────────────────────────┐ │ User Interface │ └────────────┬────────────┘ │ ┌────────────▼────────────┐ │ API Layer │ └────────────┬────────────┘ │ ┌────────────▼────────────┐ │ Business Logic Layer │ └────────────┬────────────┘ │ ┌────────────▼────────────┐ │ Data Access Layer │ └─────────────────────────┘ ``` * The _Data Access Layer_ (DAL) provides a strongly-typed API through which upper layers can access DSC's database. The functions of the DAL offer some level of filtering capabilities. However, the strongly typed API does not reflect the level of flexibility of the UI. Therefore, the DAL often returns way too many rows and columns. * The _Business Logic Layer_ (BLL) serves as a conduit, relaying requests to the DAL with minimal intervention. It only engages in substantive logic processing in certain domains, such as currency exchange rates and the conversion between metric and imperial units. * The _API Layer_ presents a RESTful web API that acts as the communication bridge between the BLL and the UI. This layer encapsulates the functionalities of the underlying levels into a web-accessible protocol that can be consumed by browser-based clients. * The User Interface Layer (UI) is unusually logic-heavy. This is primarily due to the lower layers' lack of agility, which has compelled the UI to take on additional responsibilities regarding data filtering and projection. Efforts to enhance performance via client-side caching by the UI team have yielded limited success. The central challenge is apparent: The original layered architecture was conceived for a more static UI environment. With the evolution of DSC's needs, the UI now demands far greater flexibility than what the current API and supporting architecture can provide. This mismatch results in excessive data retrieval and transmission to the client-side, culminating in notable performance bottlenecks and scalability constraints. ### Polling Problems A key feature of the User Interface (UI) that's putting a substantial strain on the backend infrastructure of the Digital Shop Counter (DSC) is the auto-refresh mechanism. This functionality allows users to passively monitor the UI, where they receive visual notifications upon any alterations within the system, such as the status updates of orders. Currently, the UI lacks a direct subscription model to listen for changes occurring in the deeper layers of the architecture. To circumvent this limitation, it repeatedly sends requests to the API to fetch fresh data, subsequently performing a comparison between this newly retrieved data set and the one previously held. Any detected changes are then flagged and visually accentuated for the user. ### Code Duplication (aka _Sinkhole_ Antipattern) In your examination of the system's architecture, you have uncovered a notable redundancy issue: the BLL often functions merely as a conduit, passing requests directly to the DAL without any modification. Despite this, the architectural design mandates that the BLL provides a complete suite of APIs — including distinct _Data Transfer Objects_ (DTOs) — to the API layer. This requirement has led to an excessive amount of boilerplate code, which we recognize is neither efficient nor sustainable. ## Technical Details The order management part of DSC has been written with C# and .NET. The codebase is maintained to align with the most recent Long-Term Support (LTS) release, .NET 6. Proactively, there are plans in place to migrate to .NET 8 within the first quarter of its release. The platform is grounded on a relational database system, with data interactions managed through Entity Framework Core, ensuring an efficient and effective ORM solution. Each layer of the architecture communicates upwards through rigorously defined APIs. These APIs leverage _Plain Old CLR Objects_ (POCOs) as _Data Transfer Objects_ (DTOs) for the exchange of information. The API layer itself is crafted using _ASP.NET Core_. ## Your Tasks ### Advanced Query Capabilities Revise the layered architecture to enable more sophisticated querying capabilities, thereby allowing data filtering and property selection at the database level rather than in the UI. If you are familiar with the development technologies mentioned above, be as specific as possible (e.g. sketch sample use cases with concrete suggestions for API structure). ### Code Duplication Conceptualize a solution for the code duplication problem. * How might we refactor the BLL to minimize code duplication while still fulfilling its role? * What design patterns or architectural strategies could be employed to reduce the overhead of transforming and passing data between layers? * Are there opportunities to enhance the existing data models to better serve the needs of the BLL, thereby eliminating unnecessary DTO proliferation? Think critically about the balance between maintaining clear separation of concerns and optimizing the flow of data within DSC. Your proposed solutions should aim to reduce complexity, improve maintainability, and increase the efficiency of the architecture. ### Duplex Communication Suggest an approach for eliminating the current polling mechanism by establishing a bidirectional communication channel between the server and the client. How would the communication between API and UI layer work in your architecture? Which protocols/standard would you use? How would bidirectional communication be embedded in the layered architecture? ### UI Layer Enhancements Propose a structure of the UI layer so that it can interact with the new duplex communication channel and handle real-time data updates effectively.