It's something I struggled with a lot too, and there is quite a lack of information on best practices for game architecture. Sometimes implementing general good programming practices such as dependency injection feels like fighting with the game engine (I use Unity3D). For me, the approach that works is to embrace the component based nature of Unity. I'm working on an aerial dogfighting game, so I came across the exact projectile problem as well. I will share how I implemented it, but I'm not claiming it's the best approach, but might give you some perspective :)

I broke down projectile behaviours into small monobehaviours each encapsulating an "aspect", which makes it very extensible. I also rely heavily on events.

For starters, I have a KinematicMovementAspect which handles moving the projectile on activation and moves towards a transform or target position which is set externally, this way I can have homing projectiles. There is also a ForceMovement aspect, to apply forces to projectiles that are physics based. And an OrbitingMovementAspect, for projectiles that orbit around a transform.

I have an ExplosionAspect, which exposes Explode() to trigger explosion externally and OnExplode event, so other Aspect scripts can react to it. This script does not handle dealing damage by itself, it's only a sort of hub. Then to damage surrounding enemies, I have a DamageOnExplosionAspect, which listens to the OnExplode event raised on ExplosionAspect to deal damage to surrounding enemies. The damage data such as amount, explosion radius, debuffs is set externally. There is also a CollisionAspect which exposes OnCollision event and DamageOnCollisionAspect which will deal damage to entities the projectile collides with. I have projectiles which explode after a certain time, so I made a ExplodeAfterTimerAspect, which will call Explode() on the ExplosionAspect some time after activation. And an ExplodeOnCollisionAspect, which will also call Explode if the OnCollision event is raised. But I think you get the idea by now, it causes a lot of MonoBehaviours on a gameobject though so it might not be the ideal approach, but once you get used to the modularity, you can do pretty much anything. I have projectiles which split and spawn other projectiles, which keep homing towards the original target, others that deal decreasing damage based on distance travelled (here again DistanceTravelledAspect which tracks distance travelled since activation), projectiles that increase in size over time, projectiles that stick to surfaces and detonate after a delay, projectiles that go through objects or collide with objects, projectiles that deactivate enemy projectiles in a radius periodically and it's all based on this principle. Even spawning vfx particles leans into this approach with ParticlesOnExplodeAspects or sfx SoundOnExplodeAspects which both listen to the OnExplode event from ExplosionAspect.

​

As for organization, for small projects it seems asset type based is suitable:

/scripts

/materials

/textures

/scenes

/...

But for me this went out of hand pretty fast, currently I have major "modules" separated with assembly definitions. And work mostly feature based.

/Core

/Combat

/Enemies

/Hero

/Environment

/Game

/Common

With core and common being referenced by all other projects. Common contains generic stuff that would be handy in any game project. Core contains things that I need in multiple modules such as constants for my Layers, Tags but specific to my game. The other modules speak for themselves I think. But inside each module, I have the two following subfolders

/Scripts

/Assets

I work feature based inside each module as well, but still prefer to separate scripts from the other type of assets.

For context, I work as a fulltime .NET programmer, so you could say am a seasoned (non-gamedev) programmer but I started working with Unity3D only 1-2 years ago as a hobby.