Cleanup Java package structure

[t2gran]

For example OTP do not have a shared core model for types like I18NString. Creating a clean domain model with rich business functionality will make it much easier to maintain, and work with OTP. The ongoing cleanup of the transit model is part of this, but this also apply to other parts of OTP as well.

I would like to suggest some general concepts and illustrate this with an example. If we can agree on the concepts, then we can start migrating toward such model.

Concepts

1. o.o.<domain>.<component>.<sub-component> Code should be organized by domain functionality, not technology.
2. o.o.<domain> At the top level we should divide OTP into "domain"s like apis, framework, transit, street, astar, raptor, feeds, updators, and application.
3. component and sub-component, a group of packages/classes witch naturally belong together. Sometimes an aggregate(DDD).
4. Package api - Used for components to define the programing interface for the component. If present, (see Raptor) all outside dependencies to the component should be through the api - never bypass it, with one exception - creating the component.
5. Package model - A model as in DomainDrivenDesign like: o.o.transit.model
6. Package service - Like Spring service, the main access-point to interact with the component. In DDD the main access point is the aggregate root, but a service provide access to the aggregate root, and may provide frequenty used utility methods for access to other parts and edit it. The XyzService interface can also be at the root level of the api package.
7. Package configure - Component creation/orchestration
8. Package support - Sometimes domain logic get complicated, the extracting/isolating it helps - it isolate the logic and the core domain classes get simpler (the complex stuff is extracted). support is used internally in a component, not outside.
9. Package framework - (Abstract) building blocks internal to a domain/parent package. In some cases accessed outside the component.
10. Package mapping - Map between two domains.
11. Package util - General "util" functionality, often characterized by being "static". Dependencies to other OTP packages is not allowed, only 3rd party libs witch can be considered utils them self. util packages can exist on any level, depending on generality/usage.
12. Package o.o.apis - OTP external endpoints. Note! Many apis are in the Sandbox where they are in the o.o.ext package.

org.opentripplanner (o.o)
  apis
    rest
    index
  application       -- now standalone, wire OTPMain together - no bussiness logic
    OTPMain       
  astar             -- AStar algorithm implementation, the specifics is in `o.o.street.model`
  feeds
    gtfs
    elevation  
    netex
    osm             -- Merge `o.o.graph_builder.module.osm` and `o.o.openstreetmap`
      model
      builder          
  framework
    model           -- I18n, FeedScopedId, P2, T2, OTPApplicationException
    datastore
    graphbuilder    -- abstract building blocks, not the concrete builders
  raptor
  routing           -- A lot of the todays content should be moved outside the routing package
    model           -- Routing model(api), request and response
    service
    filterchain            -- Sub-component 
    transferoptimization   -- Sub-component
  street
    model  
  transit
    model
    service       
  geometry          -- Working with the geometry deserves its own domain, needs sub-components
  util              -- General utils used by at least two of the domains
    lang
    time
    logging 

TODOs

• Where do visualizer go? o.o.apis or o.o.tools
• Where do inspector go?

See also the discussion: https://github.com/opentripplanner/OpenTripPlanner/issues/4284#issuecomment-1190100861

Here is the dependency matrix BEFORE (dev-2.x 2022-11-24) - More than several tousen cyclic dependencies:

[github-actions[bot]]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 30 days

[github-actions[bot]]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 30 days

[github-actions[bot]]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 30 days