T1(customer): add domain entities, Gender enum, and ICustomerService interface

[devin-ai-integration]

Summary

Adds the foundation domain layer for the Customer microservice — pure types with zero business logic and no cross-context references.

New files:

• Customer.Domain/Entities/Customer.cs — domain entity with identity, contact, audit, and Gender properties
• Customer.Domain/Enums/Gender.cs — enum Gender { None, Female, Male }
• Customer.Domain/Interfaces/ICustomerService.cs — async CRUD contract (GetAllAsync, GetByIdAsync, CreateAsync, UpdateAsync, DeleteAsync)

Gender is resolved from Customer.Domain.Enums; interface methods reference the entity via Entities.Customer to disambiguate from the root Customer namespace.

Removed .gitkeep placeholders from Entities/ and Interfaces/.

Validated: dotnet build Customer.Domain.csproj -c Release and dotnet build Customer.API.csproj -c Release both succeed. Zero forbidden references (Order, Product, ApplicationUser, ApplicationDbContext).

Part of the Customer microservice carve-out stacked PR chain (T1/T5).

Link to Devin session: https://partner-workshops.devinenterprise.com/sessions/df4fd98794c34738bf5a70c588276dcb
Requested by: @mbatchelor81

---

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment, CI, and merge conflict monitoring

[devin-ai-integration]

Devin Review found 1 potential issue.

[devin-ai-integration]

🚩 Class name collides with root namespace, may cause resolution issues downstream

The entity class Customer lives in namespace Customer.Domain.Entities, meaning the fully qualified name is Customer.Domain.Entities.Customer. The root namespace of the project is also Customer. This name collision is already handled in ICustomerService.cs via the Entities.Customer qualifier, but downstream consumers (in Customer.Infrastructure or Customer.API) may encounter ambiguity when they try to reference the entity — the compiler could confuse the namespace Customer with the class Customer. This is a known C# pitfall when a type shares its name with its containing namespace hierarchy. It may require global:: qualifiers or aliases in future code.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

Acknowledged — the class/namespace collision is a known C# pitfall here. The entity name Customer follows the project's domain naming convention. Disambiguation is already applied in ICustomerService.cs via Entities.Customer. Downstream consumers in Customer.Infrastructure and Customer.API can use the same Entities.Customer qualifier (or a using alias) if needed.