Home/Programming/

Software Design

100%
Domain Driven Design
Domain-Driven Design: Tackling Complexity in the Heart of Software: Evans, Eric: 8601300201665: Amazon.com: Booksamazon.com
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
Domain Driven Design and Functional Programming
Using “Smart” Constructors to Ensure Validation Rules are Applied
Avoid Domain Events within a Bounded Context (FP + DDD)
Invariants and how to express them formally in the Type System
Example of Capturing Business Rules with the Type System
Modeling Business Workflows as Pipelines
Modeling Dependencies (FP + DDD)
Selectively Passing Functions that are Needed as Dependencies
When to Make Dependencies Explicit
(Business) Consistency in DDD
The Importance of Consistency and its relationship with the Atomicity of Persistence
Tradeoffs in Achieving Consistency across Domain Context Boundaries