Architecture:
- Create companies table with company_code as unique identifier
- Add company_id foreign key to admin_users for multi-tenant support
- Implement backward compatibility with DEFAULT company for existing users
Core Components:
- Company entity with full CRUD operations
- ICompanyRepository interface following Repository pattern
- CompanyRepository with Dapper implementation
- CompanyService with business logic and validation
- CompanyController with REST API endpoints
Admin UI:
- CompanyForm reusable component (Create/Edit pattern)
- CompanyList.razor with pagination and company overview
- CompanyCreate.razor for registering new companies
- CompanyEdit.razor for managing existing companies with delete
- All pages follow admin-page-hero pattern for consistency
SOLID Principles:
- Single Responsibility: Each component has one reason to change
- Open/Closed: Extensible without modifying existing code
- Interface Segregation: Clean repository and service contracts
- Dependency Inversion: All layers depend on abstractions
Database Migration (V014):
- Creates companies table with active/inactive status
- Assigns existing admin users to DEFAULT company
- Provides foundation for role-based access control
Future Enhancement:
- Admin users can belong to specific companies
- Data filtering based on company_id (multi-tenant isolation)
- Company-based permission model
Core Components:
- Create reusable InquiryForm.razor component following SOLID principles
- Implement InquiryCreate.razor for registering new inquiries (offline, phone)
- Implement InquiryEdit.razor for modifying existing inquiries with delete
- Add DeleteAsync method to InquiryRepository and InquiryService
- Update InquiryList with 'Create' button and Edit link in table
Architecture:
- InquiryForm: Encapsulates form logic, can be reused for create/edit
- Service Layer: All operations go through InquiryService for cache invalidation
- Repository Pattern: Database operations isolated in InquiryRepository
- UI Consistency: Both pages follow admin-page-hero pattern
Features:
- Admin can create inquiries from phone/offline consultations
- Admin can modify inquiry details (name, phone, email, message, status, memo)
- Admin can delete inquiries with confirmation dialog
- All operations update dashboard cache
- Status validation and error handling throughout
Testing:
- Updated FakeInquiryRepository in tests to implement DeleteAsync
- Create BlogEdit.razor for editing existing posts
- Add admin-page-hero section for consistent navigation
- Implement delete functionality with confirmation dialog
- Add GetByIdAsync method to BlogService to support entity retrieval by ID
- Follow SOLID principles: single responsibility for each component
**Architecture Refactor (SOLID Principles):**
- Implement AdminDashboardController (REST API)
- Add dashboard summary endpoint
- Add upcoming filings endpoint
- Add recent inquiries endpoint
- Add monthly statistics endpoint
**Database Layer (Repository Pattern):**
- Extend IInquiryRepository with date range queries
- Implement CountByDateRangeAsync
- Implement CountByStatusAndDateAsync
- Extend InquiryRepository with new methods
**Service Layer (Single Responsibility):**
- Extend AdminDashboardService with API methods
- Add GetRecentInquiriesAsync
- Add GetMonthlyStatsAsync with caching
**Test Coverage:**
- Update FakeInquiryRepository mock with new methods
**SOLID Application:**
✓ Single Responsibility: Each class has one reason to change
✓ Open/Closed: Dashboard API can be extended without modifying existing code
✓ Dependency Inversion: Service depends on Repository abstraction
✓ Interface Segregation: API endpoints are focused and specific
Status: ✓ Compiles successfully (0 errors, 0 warnings)
Next phases:
- Add remaining API controllers (Announcement, Client, FAQ, TaxFiling)
- Refactor Blazor components to use API instead of services
- Implement JWT token refresh mechanism
- Add SignalR for change notifications
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- TaxSeason / CurrentSeasonDto에 RelatedCategorySlug 추가
- TaxSeasonCalendar 각 시즌에 카테고리 슬러그 매핑
(income-tax→income-tax, vat-1st/2nd→vat, 종부세→real-estate-tax 등)
- IBlogPostRepository.GetByCategorySlugAsync 추가
- BlogService.GetSeasonalPostsAsync: 시즌 관련 글 2개 우선 + 나머지 최신 글로 채움
- IndexModel: SeasonalPosts / RecentPosts 분리 로드
- Index.cshtml 블로그 섹션: 시즌 중 "이번 시즌 추천" 배지 + 시즌별 전체보기 버튼
- site.css: blog-card--seasonal, seasonal-blog-tag, btn-seasonal 스타일
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- 연간 세무 캘린더(7개 시즌) 기반 자동 Hero 섹션 전환
- 시즌 감지 시 D-Day 카운트다운, 긴박감 배지, 시즌 CTA 표시
- 서비스 카드 순서 시즌 관련 항목 우선 정렬
- 어드민 공지사항 CRUD (등록·수정·삭제, 기간·유형 설정)
- 홈페이지 상단 공지 배너 자동 노출 (일반/배너/긴급)
- CLAUDE.md에 세무 캘린더 및 마케팅 방향 하네스 추가
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
4개 API 컨트롤러 구현:
✅ AuthController: POST /api/auth/login
✅ BlogController: GET/POST/PUT/DELETE /api/blog
✅ CategoryController: GET/POST/PUT/DELETE /api/category
✅ InquiryController: POST/GET/PUT /api/inquiry
아키텍처 개선:
- Application 서비스 레이어 확장 (CategoryService 추가)
- Repository 인터페이스 CRUD 지원 추가
- Program.cs에 MapControllers() 추가
- 비즈니스 로직과 UI 완전 분리
장점:
- 향후 UI 리뉴얼 시 API 변경 불필요
- 모바일 앱, 데스크톱 클라이언트 추가 가능
- 테스트 가능한 API 엔드포인트
테스트 결과:
✅ 블로그 API: 5개 포스트 조회
✅ 카테고리 API: 5개 카테고리 조회
✅ 문의 API: 문의 제출 성공
⚠️ 인증 API: 예정된 수정 대기
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
BlogService:
- GetBySlugAsync: 공개된 포스트 조회
- GetPublishedPagedAsync: 페이징된 포스트 목록 (카테고리 필터 옵션)
- GetAllForAdminAsync: 관리자용 전체 포스트 (발행 상태 무관)
- CreateAsync: 포스트 생성 (슬러그 자동 생성)
- UpdateAsync/DeleteAsync: 포스트 수정/삭제
- IncrementViewCountAsync: 조회수 증가 (fire-and-forget)
- GenerateSlug: 한국어 제목 → 로마자 슬러그 변환
InquiryService:
- SubmitAsync: 상담 신청 폼 제출
* 이름, 전화번호 필수
* 전화번호 정규식 검증 (010-XXXX-XXXX)
* 문의 내용 필수
* ValidationException 으로 입력값 오류 처리
- GetByIdAsync/GetPagedAsync: 문의 조회 및 필터링
- UpdateStatusAsync: 문의 상태 변경
추가:
- ValidationException: 비즈니스 검증 예외
- DependencyInjection: AddApplication() 확장 메서드
Co-Authored-By: Claude <noreply@anthropic.com>
kjh2064