Skip to content

Domain Analyzer - Optimization & Refactoring Guide

Current Issues in main.go

Your main.go file has 284 lines and suffers from several problems:

  1. Argument parsing bloat (lines 26-104): Long if-else chains for command-line argument handling
  2. Business logic mixed with presentation (lines 106-195): DNS lookups, data fetching, and formatted output all intermingled
  3. Global variables for formatting (lines 15-20): Color variables scattered throughout
  4. Duplicate code patterns: Repeated domain cleaning, resolution checks, and IP lookups
  5. Helper functions in main (lines 207-284): cloudflareCheck() and checkOpenPortsWrapper() belong elsewhere

1. Create a CLI/Command Handler Module (cli/ or cmd/)

Move all argument parsing to a dedicated package: 

cli/
  ├── cli.go           # Main CLI coordinator
  ├── parser.go        # Argument parsing logic
  └── commands.go      # Command definitions and routing

Benefits: - Clean separation: main.go becomes ~20 lines - Each command becomes a clear function (e.g., RunFullAnalysis, RunSSLCheck, RunPortScan) - Easier to add new commands or flags

2. Create an Output/Formatter Module (output/)

Centralize all display logic: 

output/
  ├── formatter.go     # Color definitions and formatters
  ├── display.go       # Display functions (DisplayIPInfo, DisplayDNSRecords, etc.)
  └── styles.go        # Consistent styling

Benefits: - Reusable display functions - Easy to change output format (JSON, table, etc.) - Color definitions in one place

3. Create an Analyzer/Orchestrator Module (analyzer/)

High-level orchestration of DNS checks: 

analyzer/
  ├── analyzer.go      # Main analysis orchestration
  ├── cloudflare.go    # Cloudflare detection logic
  └── validator.go     # Domain validation wrapper

Benefits: - Business logic separated from display - Functions like AnalyzeDomain(domain string) return structured data - Easy to test without UI concerns

4. Refactor main.go Structure

Your new main.go would become ~10-15 lines - just a simple entry point that delegates to well-organized modules.

5. Move Helper Functions

  • cloudflareCheck() → analyzer/cloudflare.go
  • checkOpenPortsWrapper() → cli/interactive.go or analyzer/ports.go

Additional Improvements

  1. Error Handling: Return errors instead of calling os.Exit() everywhere
  2. Configuration: Move port lists and timeouts to a config struct or file
  3. Testing: With separated concerns, you can unit test each module
  4. Dependency Injection: Pass dependencies (domain, options) as parameters, not globals

Do You Need to Learn Design Patterns?

Not necessarily! The refactoring I suggested is more about basic software engineering principles than formal design patterns.

What You Really Need to Know

1. Separation of Concerns (Most Important)

  • Put related code together
  • Keep unrelated code apart
  • Each module does one thing well

This is just common sense organization, not a formal pattern.

2. Basic Go Package Structure

  • How to create packages (package cli)
  • How to export functions (uppercase names)
  • How to import between packages

You already know this - you have dns_checks package!

3. Function Design

  • Functions should accept parameters, not use globals
  • Return errors instead of calling os.Exit()
  • Return data structures, not print directly

Design Patterns That Apply (But You Don't Need to Study Them)

Your refactoring naturally uses some patterns, but you don't need to memorize them:

  1. Command Pattern (cli package) - just means "each CLI flag runs a different function"
  2. Facade Pattern (analyzer package) - just means "one simple function that coordinates many smaller ones"
  3. Dependency Injection - just means "pass things as parameters, not globals"

Practical Learning Approach

Instead of studying design patterns, just:

  1. Look at well-structured Go projects:
  2. kubectl (Kubernetes CLI)
  3. gh (GitHub CLI)

  4. cobra CLI framework examples

  5. Follow these simple rules:

  6. If a function is >50 lines, break it up
  7. If you're passing the same 3+ parameters everywhere, make a struct
  8. If you see copy-paste code, extract a function

  9. If main.go is >100 lines, move code to packages

  10. Refactor incrementally:

  11. Start with one small piece (e.g., just the help command)
  12. Move it to a new package
  13. Make sure it still works
  14. Repeat for the next piece

Migration Priority

Phase 1: Create cli/ package, move argument parsing

  • Extract all the if-else command parsing logic
  • Create command handler functions
  • Test each command still works

Phase 2: Create output/ package, move all display code

  • Move color variable definitions
  • Create reusable display functions
  • Replace direct prints with display function calls

Phase 3: Create analyzer/ package, move orchestration logic

  • Move cloudflareCheck() and checkOpenPortsWrapper()
  • Create high-level analysis functions
  • Separate data retrieval from presentation

Phase 4: Refactor dns_checks to return data structures instead of printing

  • This is optional but improves testability
  • Makes the package more reusable

Quick Wins (What to Do First)

If you want to start small:

  1. Create output package first: Move color definitions and display functions
  2. Extract cloudflareCheck(): Move to separate file in main package first
  3. Add a config struct: Instead of global variables
  4. Extract one command: Move --help to separate function

Even these small changes will make a big difference!

Expected Results

This refactoring will: - Reduce main.go from 284 lines to ~10 lines - Make the codebase 3-5x easier to maintain - Enable unit testing and future enhancements - Follow Go best practices

Bottom line: You can do this refactoring with the Go knowledge you already have. Design patterns help you name what you're doing, but aren't required to do it. Start small, test frequently, and refactor incrementally!