Naslo — SewTec E-commerce Platform

Naslo is the internal codename for SewTec's next-generation e-commerce platform — a full rebuild of their Shopify storefront (sewtecstore.com) into a custom Arabic-first system for industrial sewing machines and spare parts. I'm the backend architect and full-time software engineer on it.

Business Analysis: Three Journeys, One Platform

Before writing a line of backend code, the business domain had to be mapped. SewTec doesn't sell like a normal store — the same catalog behaves completely differently depending on who's buying:

The 8 Open Questions

The backend analysis doc (PR #4) identified 8 business questions that must be answered before data/API design can begin. They're business questions, not technical ones — the answers live with SewTec's sales and warehouse teams:

• Q-01: First-release scope — which journeys ship in v1?

• Q-02: How is stock managed today? (No real-time stock in v1 — manual confirmation)

• Q-03: Who approves dealer eligibility, and on what basis?

• Q-04: After a quote request — converted to order, or negotiated offline?

• Q-05: Who sets prices? How is shipping computed per region?

• Q-06: Payment providers (COD + bank transfer at launch)

• Q-07: Multi-brand catalog ownership and spare-part compatibility

• Q-08: Production-line request workflow

System Architecture

The system is split into two deployables: a Next.js frontend (client-rendered, Arabic RTL) and a .NET backend (planned: .NET Aspire, Clean Architecture, CQRS with MediatR). The frontend currently runs on mock data + localStorage — the backend contract is being designed to replace it without frontend rewrites.

Frontend Layering (built)

The frontend follows strict layering — domain/ owns types and never imports from other layers. The storefront section system is a textbook example:

Backend Design (in progress)

The backend follows Clean Architecture with CQRS. Here's the pattern for the dealer quote flow — the most complex journey:

// Command: dealer requests a quote (not an order — a request)
public record RequestQuoteCommand(
    Guid DealerId,
    List<QuoteLineDto> Lines
) : IRequest<Guid>;

// Handler: validates dealer eligibility, creates Quote aggregate
public class RequestQuoteCommandHandler : IRequestHandler<RequestQuoteCommand, Guid>
{
    public async Task<Guid> Handle(RequestQuoteCommand cmd, CancellationToken ct)
    {
        var dealer = await _context.Dealers
            .FirstOrDefaultAsync(d => d.Id == cmd.DealerId, ct);
        
        if (dealer?.Status != DealerStatus.Approved)
            throw new UnauthorizedException("Dealer not approved");
        
        var quote = Quote.Create(dealer.Id, cmd.Lines);
        _context.Quotes.Add(quote);
        await _context.SaveChangesAsync(ct);
        
        return quote.Id;
    }
}

Key design decision: a Quote is NOT an Order. It's a separate aggregate with its own lifecycle (Requested → UnderReview → Approved/Rejected → ConvertedToOrder). Merging them would have been simpler short-term but wrong — the business treats them as different things with different actors (dealer vs sales team).

Domain-Driven Design: The Catalog Problem

SewTec sells machines AND spare parts across multiple brands (ZOJE, Jack, Siruba...). A spare part isn't just a product — it's compatible with specific machine models. This is a classic DDD aggregate design problem:

Dual Pricing: The Hardest Domain Problem

Guests and retail accounts see fixed prices. Dealers see NO prices — they request quotes. This isn't a UI toggle; it's a domain invariant:

public class PricePolicy
{
    public static Money? ResolvePrice(Product product, Customer customer)
    {
        return customer.Type switch
        {
            CustomerType.Guest => product.RetailPrice,
            CustomerType.Retail => product.RetailPrice,
            // Dealers never see fixed prices — they negotiate per quote
            CustomerType.Dealer => null,
            _ => throw new DomainException($"Unknown customer type: {customer.Type}")
        };
    }
}

Returning null for dealers (not zero, not hidden in the UI) makes the invariant explicit in the domain layer. The frontend can't accidentally show a dealer a price — there's no price to show.

Current Status

• Frontend: Next.js 16, 7 section types, studio editor with undo/redo, draft/published workflow — live in preview

• Backend analysis: 8-phase doc complete, 8 business questions identified, awaiting operational validation

• Backend implementation: Clean Architecture + CQRS design in progress, starting with the quote aggregate

• Next: answer Q-01 through Q-04 with the sales team, then data model + API contract