That doesn't sound right. Domain-driven design is just a technique to design a data model that fits your application domain, and designs the whole application around that data model.
To put it differently, with DDD first you define a data structures, and afterwards the application is just operators over said data structure.
The only reason why in DDD you would care about whether "a penguin is a fish or a bird" is if your businesses required handling fishes or birds in fundamentally different and incompatible ways, which would require you to write special purpose code that crossed all layers.
It sounds like you've been experiencing a kind of analysis paralysis with the DDD tag.
Reading this I guess you followed the wrong course. One that shoved you Tactical Patterns down the throat without explaining well-enough why you should use them. DDD in the core is not about architecture, but about *common understanding* of the domain, *before* you start coding and hacking on a particular architecture. The domain understanding should help you make appropriate architecture decisions, but in now way dictate what architecture designs to use.
Data-DD is focus on data and keep it simple. Domain-DD is another one of these architecture astronauts fads where you introduce new abstractions and then spend most of the time wondering whether penguin is a bird or a fish for the purpose of your application.