Timeline for Decoupling UIs from Domain logics | Clean architecture
Current License: CC BY-SA 4.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 30 at 11:02 | answer | added | Bart van Ingen Schenau | timeline score: 2 | |
| Sep 30 at 10:39 | comment | added | Steve | Every theorist of architecture talks a good talk on decoupling. I've never heard of any of them who explicitly advocated for coupling under any circumstance. What hardly any of them talk about is what kinds of coupling are intrinsic or necessary to accept, or what the limits of decoupling are. | |
| Sep 30 at 10:21 | review | Close votes | |||
| Oct 7 at 3:04 | |||||
| Sep 30 at 9:27 | answer | added | Ewan | timeline score: 0 | |
| Sep 30 at 8:59 | comment | added | Flater | Your overall approach may be well intentioned but it is deeply misguided. You're trying to shoehorn badly designed code into a format that inherently resists putting bad code into it, and you're doing it while stating that certain things have to remain the same regardless what the new architecture mandates. This is just not going to end well for you learning to do things the clean way. | |
| Sep 30 at 8:56 | comment | added | Flater | It is way harder to break up tightly coupled unlayered code than it is to design code from scratch the right way, let alone trying to apply an architecture that you're still new to. I strongly suggest that your first hands-on experience is not refactoring an existing codebase. | |
| S Sep 30 at 8:43 | review | First questions | |||
| Sep 30 at 11:06 | |||||
| S Sep 30 at 8:43 | history | asked | codingenious | CC BY-SA 4.0 |