How to build a class structure, when members are a

I'm building a PHP web application, that should provide to the user a possiblity to order an "installation"/setup of a (ConnectDirect or File Transfer Gateway) connection between him and another person/organization.

(The technical specifica of the connection implementation are not important -- in the application it's only about the connections as product, that can be ordered and managed.)

The classes hierarchy for its model layer should represent following real-world infrastructure:

There are connections, that can be ordered.
A connection can be an IBM Connect:Direct connnection or an IBM File Transfer Gateway connection.
A CD connection is direct from A (source) to B (target).
A FTGW connection consists physically of two connections: A (source) to the FTGW server and from the FTGW server to B (target) -- but logically (for the ordering user) it's also one connection.
(There is additionally a case of an FTGW connection, that uses Connect:Direct as protokoll.)
Every endpoint is either a source or a target.

So I see following logical elements: logical connection, physical connection, role (source and target), connection type, order, endpoint, endpoint type (CD and FTGW).

The structure I currently have looks like this:

But there are some issues with it:

There are two hierarchy trees, where each element of the one consists contains elements of a particular subset of the other (each CD connection consists of CD endpoints; each FTGW connection consists of two FTGW endpoints, or more correctly: each FTGW logical connection consists of two physical FTGW connections -- and each of them consists of an FTGW endpoint and the FTGW server as second endpoint).

An alternative might be to replace the relationship betweet Endpoint and PsysicalConnection by two relationships: EndpointCD-PsysicalConnectionCD and EndpointFTGW-PsysicalConnectionFTGW.

Pro: More consistent; eliminates the logical imprecision (or maybe even mistake) of the faked possibility to build every connection (type) from a pair of any endpoints. Contra: Actually the requirement to contain two endpoints is a characteristic of every psysical connection -- from this point of view the right place for this is the very basic PsysicalConnection class.

Every endpoint can be both source and target and contains not only the common endpoint properties, but also source and target properties. That means, dependent on the currnt role of the endpoint some properties are waste. And this will also be influence the database structure (columns, that sometimes have to be set and sometimes have to bi NULL).

An alternative is to extend the hierarchy...

a. ...by classes like EndpointSource and EndpoitTarget inheriting directly from the Endpoint and being inherited by the classes EndpointCD and EndpointFTGW (that means: two identical subtrees -- under EndpointSource and under EndpointTarget);

b. ...by classes like EndpointCDSource and EndpointCDTarget (inheriting from the class EndpointCD) and EndpointFTGWSource and EndpointFTGWTarget (inheriting from the class EndpointFTGW) being inherited each by the concrete CD or FTGW endpoint classes (that means: twice two identical subtrees);

c. ...by classes like MyConcreteEndpoint***Source and MyConcreteEndpoint***Target inheriting from the concrete endpoint classes (that means: every MyConcreteEndpoint class becomes abstract and gets two sublesses -- MyConcreteEndpoint***Source and MyConcreteEndpoint***Target, e.g. EndpointCDLinux is now abstract and is inherited by EndpointCDLinuxSource and EndpointCDLinuxTarget).

Pro: eliminates the waste properties. Contra: A (more) complex class hierarchy.

Well, it's about software architecture and should (and of course will) be my design decision. But it would be nice to hear/read some expert (or non-expert) thougts, how to handle such a case. What are proper ways to organize the logical items for an infrastructure like what I described?

Maybe I am overthinking, but I suggest for you to use slightly different model to reflect your business logic.

Following could be a total misunderstanding, but I'll give it a shot.

So:

Basing on what in fact any connection is, here is a concept:

Every connection is a collection of Nodes through which data should travel in order to reach its destination.
Each node can connect with next node using specific protocol, which is specific only to direct connection between two particular nodes.
Protocol has its own properties common for source and target nodes

Basing on this I suggest following model of building, managing and storing a configuration of Product:

Here:

LogicalConnection is reference to built composition of actual Connection, Node and Protocol classes
Connection contains a double-linked list of Nodes which are composed in order as data flows. i.e.: 1st element is source node and 2nd is its target and so on.
Concrete Node contains platform specific configuration, reference to target (*Node), source node (*Node) and concrete protocol (*Protocol)
Protocol contains its specific configuration for source and target, Node instances may refer to Protocol instance to extract required configuration.
Target and Source Nodes "see" each-other and source-target protocol configuration via double-linked list structure.
Configurations\*ConfigBuilder implementations orchestrate process of accepting data from UI and transforming it into actual composition of Connection, Node and Protocol depending on case.
IBM\ConnectDirect\ and IBM\FTGW\ namespaces contain concrete realizations for Protocol and *Node (e.g. WindowsNode, UnixNode)

If there still is a need for Node or Protocol to contain both source and target related attributes and part of them still could be NULL in some configurations - I suggest to use EAV storage model for DB if there is any concern about unused columns etc..

Using suggested model connections you described in question could be represented as following:

Connection:IBM_CD {
  nodes:[
    {//LinuxNode
      target:*nextElement,
      protocol:{//IBM.ConnectDirect.Protocol
        ..target attributes..
        ..source attributes..
      }
      ..platform specific attributes..
    },
    {//WindowsShareNode
      target:*nil,
      protocol:{
        //IBM.ConnectDirect.Protocol(same instance or null)
      }
      ..platform specific attributes..
    },
  ]
}

Connection:IBM_FTGW {
  nodes:[
    {//LinuxNode
      target:*nextElement,
      source:*nil,
      protocol:{//IBM.FTGW.Protocol
        ..target attributes..
        ..source attributes..
      }
      ..platform specific attributes..
    },
    {//IntermediateServerLinuxNode
      target:*nextElement,
      source:*prevElement,
      protocol:{//IBM.FTGW.Protocol
        ..target attributes..
        ..source attributes..
      },
      ..platform specific attributes
    },
    {//WindowsShareNode
      target:*nil,
      source:*prevElement,
      protocol:*nil,
      ..platform specific attributes..
    }
  ]
}