Should a Serverless Cloud Function Be Implemented Inside UI Layer (DDD)?

Question

I'm currently implementing a trading bot using Python and I have the following design:

DAL:

• StocksRepository

Domain:

• RecommendationService
• StocksDataCollectionService

UI:

• bot.py: a function that buys recommended stock every day at specific time
• simulator.py # simulating trading stocks on historical data

My questions are:

- Should I place the bot and the simulator in the same layer?
- Should I call this layer UI layer, or should I call it Application?
- What are the flaws of my design and things that could be named better?

** the bot and the simulator could even be separate projects, however, they still use the same business logic
and share a lot of commonalities so I'm wondering what is the best way to design a system that allows
multiple projects to use it.

For the sake of simplicity, the design above does not contain every component.
The full design is:

DAl:

• SqlStocksRepository
• SqlSymbolsRepository

Domain:

• services:
  • StocksDataCollectionService:
    • external_market_api_1
    • external_market_api_2
  • RecommendationService:
    • trading_strategy_1
    • trading_strategy_2
• entities:
  • Stock
  • Symbols
• interfaces:
  • IStocksRepository
  • ISymbolsRepository

UI:

• trading_bot:
  • main.py
• trading_simulator:
  • main.py
  • simulator.py # Feels like if it's in the domain layer it's an ISP violation, correct me if I'm wrong

simulator.py explanation

the purpose of the simulator is to run a simulation based on date range, stocks symbols pool, and a trading strategy a simplified version:

class Simulator:
  def run(
    self,
    initial_money_amount: float,
    symbols: List[str],
    trading_strategy: TradingStrategy,
    date_range: Tuple[float, float]=(NOW-YEAR, NOW)
  ) -> SimulationResult:
    pass

Answer 1

Should I place the bot and the simulator in the same layer?

Since both are entrypoints, they should be separated in two projects. Since they share code from the domain and persistence layers, these should be implemented as libraries and referenced by both projects. However, since you only have a limited amount of code, it is probably more maintenance burden than beneficial. Separation would be useful if you had different people maintaining different layers for instance.

Should I call this layer UI layer, or should I call it Application?

Basically code in this layer do manage both the presentation and the hosting responsibilities, so you can use any name. Merging presentation and hosting is a classic approach to layered architecture. Separating both layers is usually more maintenance burden than beneficial, once again.

What are the flaws of my design and things that could be named better?

This is quite an opinionated question. I prefer using plain names rather than acronyms, such as persistence, presentation or hosting, rather than DAL or UI, unless I don't have access to autocompletion tools and length matters. Also I would suggest to replace the _1 and _2 suffixes with more explicit names.