README Updates: Types-specific crates and their purpose

README.md

@@ -694,6 +694,33 @@ AWS deployments.
 See cargo workspace members:
 [Cargo.toml](Cargo.toml)
 
+#### Types-specific crates and their purpose
+
+The workspace includes several -types suffixed crates that handle domain models, type definitions, business logic and
+conversions:
+
+* **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.
+
 #### Naming: why keeping prefix drive-deposits
 
 Using the "drive-deposits-" prefix for crate names clearly distinguishes these as separate crates within