Internal Framework

Context

Internal class library project providing dtos, a service-layer, and data access layer for use by multiple internal web applications.

Architectural Decisions

• Business Objects were defined here for reuse.
• Service layer encapsulated business logic.
• Data access layer handled database interactions.
• Became authoritative source for member and other data during its lifespan.
• Implemented using .NET Framework 3.5 and eventually migrated to 4.7.2 for compatibility with existing internal applications.
• Service layer was used as the public interface for all consuming applications to ensure consistent business logic and data access patterns.

Challenges

• Providing the correct amount of granularity in naming to make business objects and services discoverable and understandable.
• Providing complex data access patterns while maintaining performance.
• Ensuring coding standards across what became a polyglot codebase as multiple teams contributed over time.

Outcomes

• Standardizing business objects and data access patterns across multiple internal applications ensured consistency when accessing and manipulating data.
• Service layer provided a single point of business logic enforcement, reducing duplication and potential errors.
• Service layer facilitated adding logging and caching mechanisms in a centralized manner.

My Role

Started the project as Lead Developer, defining architecture and coding standards. Maintained the project as multiple teams began contributing, ensuring consistency and quality.

Notes

The project started as a companion to the Call Center application but grew to be used by multiple internal applications over time.

Company-wide, we decided that all database access would go through this project alone to ensure consistency and reliability of data access patterns.

The data layer was hidden behind the service layer to ensure that all business logic was enforced consistently across all consuming applications.

Tech Stack