3 ms·
That article misses some important nuances. Yes hard coding business logic can land you in hot water. But you don't need to do that domain driven design. What y
by xupybd 6y ago
That article misses some important nuances. Yes hard coding business logic can land you in hot water. But you don't need to do that domain driven design. What you do need is the domain to specify the flexibility of your design. Almost all business need an accounting system. An accounting system can be built following domain driven development. But for it to be useful to many businesses it must be flexible. So the rules around standard accounting ( the domain ) will be hard coded. But the system can still be configurable as the domain is too.
- bopbeepboop 6y agoTo elaborate — Domain driven design is about understanding the business requirements enough to know “this is fundamental to the domain” versus “this is going to change next month”. In the accounting example, when you talk to the accountants and develop an ubiquitous language, you’ll notice that long term concepts are “assets”, “transactions”, “taxes”, etc. while the transient things are exact tax rates, how transactions are structured (eg, net 30), etc. So you’d build your system to match: - A foundation of transacting assets/currency/inventory - A system for defining transaction flows - A system for reporting transaction aggregates (eg, for tax filings) Domain driven design doesn’t say which of those to hardcode versus make user configurable — it says to talk to your users until you understand the domain, then build software that reflects that. Like most good ideas, people get way too formulaic about it sometimes.
- arwhatever 6y agoInteresting to see all of the discussion on hard-coding vs configuring domain/business logic, when in reality most line-of-business app developers are never introduced to the very concept of business/domain logic, and therefore it gets strewn all throughout an application’s code based, tangled in with data retrieval, u/i concerns, and everything else.
- bopbeepboop 6y agoYes — the goal of DDD is to explain why that’s a bad idea. For two reasons. 1. It makes your code a mess. 2. You probably wrote the wrong thing anyway, because how do you know what the customer wants if you don’t even know what they do? DDD argues you should develop software by: 1. Talking to customers about the domain until you have a shared language with specific terminology. 2. Write that down as a model. 3. Write that model as software. I think one of the biggest misses in software engineering (and something I’ve seen cost $100Ms) is software developers not talking to customers about what they do with the software. Some of the worst bugs happen because domain experts mean something by a term of art that software developers misunderstand. DDD overlaps heavily with the “applied category theory” perspective on software, so DDD tends to be popular with functional programming types.
- kthejoker2 6y agoThis is literally why Fowler and Evans wrote their books, some of this "tangling" was viewed as a feature because it let a single dev own an issue and avoided the bottleneck of architecture by committee.