shakedown.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
A community for live music fans with roots in the jam scene. Shakedown Social is run by a team of volunteers (led by @clifff and @sethadam1) and funded by donations.

Administered by:

Server stats:

259
active users

#domaindrivendesign

0 posts0 participants0 posts today
Kerrick Long (code)<p>I've seen a lot of content about using <a href="https://ruby.social/tags/DDD" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>DDD</span></a> (Domain-Driven Design) with <a href="https://ruby.social/tags/Ruby" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Ruby</span></a> on <a href="https://ruby.social/tags/Rails" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Rails</span></a>, but none of it has addressed how to do the "one database per bounded context" pattern--especially in the world of Solid* and SQLite by default.</p><p>Does anybody have any strategies for this?</p><p><a href="https://ruby.social/tags/Programming" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Programming</span></a> <a href="https://ruby.social/tags/RubyOnRails" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>RubyOnRails</span></a> <a href="https://ruby.social/tags/DomainDrivenDesign" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>DomainDrivenDesign</span></a> <a href="https://ruby.social/tags/RailsConf" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>RailsConf</span></a> <a href="https://ruby.social/tags/RailsConf2025" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>RailsConf2025</span></a> <a href="https://ruby.social/tags/Architecture" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Architecture</span></a> <a href="https://ruby.social/tags/SoftwareEngineering" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>SoftwareEngineering</span></a></p>
Andrea Magnorsky 😹 🦙<p>Tomorrow we are running a workshop on Team Topologies in Virtual Domain-driven design and Domain-Driven Design Australia</p><p>We had to close registration a week+ ago because we have over 100 people registered combined. </p><p>This high number of signups talk about the problems we have in industry and the solutions we think might serve us. </p><p>Thanks a million to Luke McManus , Andy Spamer for running the workshop. Sonal Premi and Chris Simon for co-hosting. There might be more people we are yet to thank ...</p><p>It already has been an amazing learning experience, I can not wait to see how tomorrow goes.</p><p>If you are attending tomorrow you should know we are trying hard to make sure it's a great experience and that we have not run with such high numbers before, here goes to an exciting experiment! 🧪 🥼 </p><p><a href="https://types.pl/tags/teamTopologies" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>teamTopologies</span></a> <a href="https://types.pl/tags/DomainDrivenDesign" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>DomainDrivenDesign</span></a></p>
Nick Tune 🇺🇦<p>Should you design APIs based on what you (the owning team) think is the best way to expose your domain, or do you make compromises based on the needs of your API's consumers?</p><p>(API here refers to any element of the public contract of your service/subsystem/app/domain/context, such as HTTP endpoints or events.)</p><p><a href="https://hachyderm.io/tags/ddDesign" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>ddDesign</span></a> <a href="https://hachyderm.io/tags/ddd" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>ddd</span></a> <a href="https://hachyderm.io/tags/domainDrivenDesign" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>domainDrivenDesign</span></a> <a href="https://hachyderm.io/tags/api" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>api</span></a> <a href="https://hachyderm.io/tags/swArch" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>swArch</span></a></p>
Nick Tune 🇺🇦<p>Should you create a separate team to work on modernizing the legacy monolith while other teams focus on building new features outside the legacy?</p><p>This is a topic I've discussed on multiple occasions recently, and it's not an uncommon modernization question in general.</p><p>I'm generally cautious of this approach because...</p><p>1/n</p><p><a href="https://hachyderm.io/tags/architectureModernization" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>architectureModernization</span></a> <a href="https://hachyderm.io/tags/legacyRefactoring" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>legacyRefactoring</span></a> <a href="https://hachyderm.io/tags/softwareArchitecture" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>softwareArchitecture</span></a> <a href="https://hachyderm.io/tags/ddd" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>ddd</span></a> <a href="https://hachyderm.io/tags/domainDrivenDesign" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>domainDrivenDesign</span></a></p>
Nick Tune 🇺🇦<p>Quick update on my book:</p><p>4 out of 17 chapters have passed through copy editing. Target is for all 17 to be completed this month.</p><p>AFAIK, we are still on schedule for physical copies to be available this year, possibly 31st October.</p><p>Thanks for all of your support. This is a tiring process and every bit of help gives me a tiny extra bit of motivation.</p><p><a href="https://hachyderm.io/tags/softwareArchitecture" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>softwareArchitecture</span></a> <a href="https://hachyderm.io/tags/architectureModernization" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>architectureModernization</span></a> <a href="https://hachyderm.io/tags/domainDrivenDesign" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>domainDrivenDesign</span></a> <a href="https://hachyderm.io/tags/teamTopologies" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>teamTopologies</span></a> <a href="https://hachyderm.io/tags/businessArchitecture" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>businessArchitecture</span></a></p><p><a href="https://www.manning.com/books/architecture-modernization?new=true&amp;experiment=B" rel="nofollow noopener" target="_blank"><span class="invisible">https://www.</span><span class="ellipsis">manning.com/books/architecture</span><span class="invisible">-modernization?new=true&amp;experiment=B</span></a></p>
Nick Tune 🇺🇦<p>A wooden table is made from wood.</p><p>A glass table is made from glass.</p><p>Why is a coffee table not made from coffee?</p><p>This is actually relevant to domain modelling: sometimes we name things after their properties and sometimes their purpose. </p><p>And sometimes we're talking about the same physical thing from the perspective of a different subdomain where it has a different name.</p><p>These factors also play a role in determining how we decide to shape boundaries.</p><p><a href="https://hachyderm.io/tags/ddDesign" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>ddDesign</span></a> <a href="https://hachyderm.io/tags/domainDrivenDesign" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>domainDrivenDesign</span></a></p>