Domain Driven Design touches on how you can work with domain experts to model the problem in a way that makes sense. A core argument there is that good software design is heavily based on communication and developing common vocabulary with domain experts, therefore gradually improving your modeling of the real world problem at hand. Also, it emphasizes on how context matters when communicating terms and even naming things in code, which is really connected to philosophy of language matters. There is something core in these ideas which I can't really express yet because it's quite blur on my mind. It goes along the lines that: when writing software, we are expressing in a formal way our model for a specific problem or domain. Language and communication are key to this practice, as it's through them that we forge our models. So there is a connection between philosophy of language, communicative acts maybe some other areas (maybe philosophy of mathematics because software can be similar to math in a way?) and the practice of designing software.
Domain Modeling Made FunctionalPDF
Entities, Value Objects and Aggregates in DDD
(Business) Consistency in DDD
The Importance of Consistency and its relationship with the Atomicity of Persistence
Tradeoffs in Achieving Consistency across Domain Context Boundaries