From d0bb38ba0c0ae5b37b1cd6724040d888e940df4c Mon Sep 17 00:00:00 2001 From: Rohit Sachdeva Date: Thu, 30 Jan 2025 07:07:50 -0600 Subject: [PATCH] README Updates: Types-specific crates and their purpose --- README.md | 25 +++++++------------------ 1 file changed, 7 insertions(+), 18 deletions(-) diff --git a/README.md b/README.md index b94b6e4..8d97440 100644 --- a/README.md +++ b/README.md @@ -696,30 +696,19 @@ See cargo workspace members: #### Types-specific crates and their purpose -The workspace includes several -types suffixed crates that handle domain models, type definitions, business logic and -conversions: +The workspace includes several -types suffixed crates that handle domain models, type definitions, business logic, and +specific persistence: * **drive-deposits-rest-types**: REST API request/response types and validations * **drive-deposits-proto-grpc-types**: gRPC protocol buffer generated types * **drive-deposits-cal-types**: Core calculation domain models and business logic * **drive-deposits-lambda-db-types**: DynamoDB item types and conversions -This separation provides key benefits: - -1. **Dependency Management**: Keeps dependencies lean by isolating type definitions. For example, - drive-deposits-rest-types prevents REST-specific dependencies from leaking into other components. - -2. **Clear Boundaries**: Each -types crate establishes clear domain boundaries and ownership of data models. - -3. **Reusability**: Types and conversion logic can be reused across multiple crates without circular dependencies. For - example, allows in module fashion re-use of drive-deposits-rest-types crates in various crates as required without - the actual axum dependency from drive-deposits-rest-gateway-server crate. - -4. **Evolution Flexibility**: While some of these crates could be merged as modules into their consuming crates, the - current separation allows evolution of the type system. - -The -types crates represent the current optimal structure based on the system's needs. As the codebase evolves, they -could be mergedinto modules if tighter coupling provides clear advantages. +This separation provides **Clean Architecture and Maintainability**: Each type crate has a clear, single responsibility. +For example, +drive-deposits-cal-types focuses purely on calculation domain logic while delegating event bridge implementation to +drive-deposits-event-source. This makes the codebase more maintainable and easier to understand as the system grows. +Hence, the -types crates represent a mature architectural pattern that scales well as the system evolves. #### Naming: why keeping prefix drive-deposits