gaoweilina/my-blog-sqlite

1. This is a single Spring Boot application, not a split microservice system. The entry point is RuoYiApplication, with RuoYiServletInitializer for servlet container deployment. It packages both an admin back office and a blog/public site in one JVM process.

2. The core request path is classic layered MVC: Controller -> Service -> Mapper -> MyBatis XML -> Database. Most business modules follow this pattern, with entities/domain objects under each module, service interfaces plus *ServiceImpl, and SQL mappings in src/main/resources/mybatis/....

3. Security is centered on Apache Shiro. framework/shiro contains the realm, login/register/password services, session management, remember-me, and request filters such as captcha, logout, kickout, and online-session checks. This is the main boundary protecting the admin and sensitive APIs.

4. Cross-cutting behavior is mostly implemented through AOP and servlet filters. framework/aspectj handles data scope, logging, permissions, and datasource switching. framework/interceptor adds repeat-submit protection. common/xss wraps requests to filter XSS input. These sit in front of business controllers and affect many modules.

5. Data access is backed by MyBatis and MyBatis-Plus, with Druid as the connection pool. The repo also includes a DynamicDataSource, a MySQL-to-SQLite function interceptor, and separate YAML profiles for MySQL and SQLite, so persistence is configurable and partly database-portable.

6. The application is organized into two broad business areas:

- project/system, project/monitor, and project/tool are the standard Ruoyi admin platform features.

- project/emmanuel is the custom blog/product area.

This separation is important for diagramming because the first group is infrastructure/admin-oriented, while the second group is the user-facing product logic.

7. The standard platform modules include user, role, menu, dept, dict, notice, config, post, mail, logs, online sessions, server monitoring, cache monitoring, job scheduling, and code generation. These modules are mostly administrative CRUD plus operational tooling, and they reuse shared framework services for auth, pagination, logging, and Excel/export support.

8. The custom blog domain is split into several subdomains:

- emmanuel/mto for blog content management: categories, channels, tags, posts, comments, links, and public web post queries.

- emmanuel/cloud for file storage and file-business linking.

- emmanuel/memorial for board/note/timeline style content.

- emmanuel/account for account/bill/money bookkeeping.

- emmanuel/index for homepage/admin dashboard aggregation and repeat-log tracking.

These are independent bounded areas with their own controller/service/mapper stacks.

9. The UI is server-rendered with Thymeleaf templates. Admin pages live under templates/system, templates/monitor, templates/tool, and custom product pages under templates/emmanuel/.... Static assets are bundled under src/main/resources/static, including large front-end libraries and dedicated blog/cloud/homepage assets. There is no separate SPA frontend server in this repo.

10. The blog/public experience is HTML-first and heavily asset-driven. The repository contains rich editor and content-rendering libraries such as Editor.md, CodeMirror, Prism, Tocbot, Moment, and various UI kits. This supports markdown editing, code highlighting, article navigation, and public blog rendering directly from the same backend.

11. Background and real-time infrastructure is present but still inside the monolith:

- Quartz schedules jobs in project/monitor/job and framework/task.

- WebSocket support lives in framework/websocket.

- Async execution is handled by framework/manager/AsyncManager.

These are auxiliary subsystems, not separate services.

12. Operational packaging is first-class. The repo includes Docker files, shell/batch launch scripts, SQL initialization files, and database documentation. That suggests the deployable unit is the whole application plus its database, with Docker being the main containerized deployment path.