---
# (DD05) Business Logic — UserService.createUser() [8 LOC]

| Field | Value |
|-------|-------|
| Fully Qualified Name | `com.example.service.UserService` |
| Layer | Service |
| Module | `service` (Package: `com.example.service`) |

## 1. Role

### UserService.createUser()

`createUser()` performs the core user-registration operation for the in-memory user management service. Its business responsibility is to accept a candidate user name and email address, validate the email format, and then create a new `User` record with a generated identifier when the input is acceptable. This method represents the service-layer entry point for user onboarding in this sample domain and encapsulates both validation and persistence concerns inside a single transactional-style operation.

The method follows a simple validation-and-create pattern. First, it delegates email validation to `ValidationUtil.isValidEmail(email)`; if validation fails, it stops processing immediately by raising an `IllegalArgumentException`. If validation succeeds, it creates a new `User` instance using the next available ID, stores that object in the internal `users` map, and returns the created entity to the caller. In business terms, this is a create-only operation with one rejection branch for invalid contact data.

## 2. Processing Pattern (Detailed Business Logic)

```mermaid
flowchart TD
    START["createUser(name, email)"]
    VALIDATE["Call ValidationUtil.isValidEmail(email)"]
    DECISION{"Email valid?"}
    EXCEPTION["Throw IllegalArgumentException(\"Invalid email\")"]
    CREATE["Create User(nextId++, name, email)"]
    PUT["Store user in users map by user.getId()"]
    RETURN_NODE["Return User"]

    START --> VALIDATE
    VALIDATE --> DECISION
    DECISION -- "No" --> EXCEPTION
    DECISION -- "Yes" --> CREATE
    CREATE --> PUT
    PUT --> RETURN_NODE
```

**CRITICAL — Constant Resolution:**
No project constant class is referenced in this method. The only string literal is the exception message `"Invalid email"`.

## 3. Parameter Analysis

| No | Parameter Name | Type | Business Description |
|----|---------------|------|---------------------|
| 1 | `name` | `String` | The display name to assign to the new user account. It is persisted as part of the created `User` object and does not alter branching logic. |
| 2 | `email` | `String` | The email address used for identity and contact validation. It is the key input to `ValidationUtil.isValidEmail(email)` and determines whether the create operation continues or fails with an exception. |

**Instance fields / external state read by the method:**
- `nextId` - internal sequence used to assign the new user identifier.
- `users` - internal in-memory repository used to persist the created user.

## 4. CRUD Operations / Called Services

| CRUD | SC / CBS | SC Code | Entity / DB | Operation Description |
|------|----------|---------|-------------|----------------------|
| R | `ValidationUtil.isValidEmail` | N/A | N/A | Validates the email format before the create operation proceeds. This is a business rule check rather than a database read. |
| C | `User` constructor (`new User(nextId++, name, email)`) | N/A | `User` | Creates a new user business object and assigns the next generated identifier. |
| C | `users.put(user.getId(), user)` | N/A | `users` in-memory map | Persists the created user into the service’s internal repository. |

## 5. Dependency Trace

| # | Caller (Screen/Batch) | Call Chain (Full Path to this Method) | Terminal (SC / CRUD / Entity) |
|---|----------------------|--------------------------------------|-------------------------------|
| 1 | Controller: `UserController` | `UserController` -> `UserService.createUser` | `users.put(user.getId(), user) [C] users` |

## 6. Per-Branch Detail Blocks

**Block 1** — **IF** `!ValidationUtil.isValidEmail(email)` (L13)

> Business rule gate that rejects malformed email addresses before user creation.

| # | Type | Code |
|---|------|------|
| 1 | CALL | `ValidationUtil.isValidEmail(email)` |
| 2 | RETURN | `throw new IllegalArgumentException("Invalid email");` |

**Block 2** — **ELSE** `email is valid` (L15)

> Continues the create flow when the email passes validation.

| # | Type | Code |
|---|------|------|
| 1 | SET | `User user = new User(nextId++, name, email);` |
| 2 | SET | `nextId++;` // post-increment embedded in constructor argument |
| 3 | EXEC | `users.put(user.getId(), user);` |
| 4 | RETURN | `return user;` |

## 7. Glossary

| Term | Type | Business Meaning |
|------|------|------------------|
| `User` | Business object | User account record containing identifier, name, and email. |
| `name` | Field | User display name used for account identification in the application. |
| `email` | Field | Email address used as the user’s contact and validation attribute. |
| `nextId` | Field | Internal sequential identifier generator for newly created users. |
| `users` | Data structure | In-memory repository that stores created user records by ID. |
| `ValidationUtil` | Utility | Shared validation helper used to verify input quality. |
| `isValidEmail` | Method | Email-format validation rule that determines whether user creation is allowed. |
| IllegalArgumentException | Exception type | Runtime error thrown when input violates a required business rule. |
| CRUD | Acronym | Create, Read, Update, Delete — standard data operation classification. |
| Service | Layer term | Business logic layer that orchestrates validation and persistence. |
| Controller | Layer term | Presentation/API entry point that invokes the service method. |