DDD Weekly: Issue #65

Core Domain Patterns [blog] Nick Tune. I find assessing bounded contexts for business differentiation and complexity a very practical and approachable starting point. For teams who have little understanding of how their architecture connects to the business model, I’ve found this technique to be incredibly useful at enabling developers to reason more about the business perspective, and especially the evolution over time.

How to Become a Great Software Architect [video] Eberhard Wolff. Software architecture is very simple: You only have to split up one system and use modern approaches such as DDD or Microservices. This presentation shows completely different qualifications that a good software architect must have. The focus is on the technical decisions that an architect has to make, how to best deal with such decisions and how to find out on what basis decisions can be made.

Facilitating Knowledge Crunching with Domain Storytelling [blog] Mufrid Krilic. Facilitation was perceived as a a very intense exercise and in Domain Storytelling the book there are several suggestions that help you address the very same issue. My small piece of advice, in case you need to facilitate a workshop on your own, is to have a rather strict schedule with regular breaks after each hour at maximum.

Conway’s Law Is Temporal: Why Tech Strategy & Vision Matters [blog] James Hickey. Conway’s law shows us that having an overall tech strategy for your software business is essential to its future stability and growth!

Notifications or Queries for Domain Communication [blog] Duncan Jones. When systems are partitioned into separate domains or indeed into separate microservices they each need to own all the data they use. This gives them a higher degree of autonomy which is the root of all the benefits we can expect to get from such an architecture.

Moving Towards Domain Driven Design in Go [blog] Jon Calhoun. In this article we looked firsthand at the problems encountered when code is tightly coupled, and we explored how defining domain types and interfaces can help improve this coupling. We also discussed some of the reasons why it might not be the best idea to start off with this decoupled design, and to instead let our code evolve over time.

Kotlin and Domain-Driven Design - Value Objects [blog] Florian Benz. Kotlin makes working with value objects fun. A common complaint from Java developers is that wrapping and especially mapping values adds too much boilerplate. I rarely hear this from Kotlin developers. But no matter the language, overusing value objects outside of the core domain can be overkill. Also, note that DDD is not a fit everwhere. Our experience with DDD in cases where we have a lot of business logic is very positive: discussions are more focused, new joiners pick up the code and logic quicker, and the burden to add features months after the initial implementation is lower.

An Engineering Team where Everyone is a Leader [blog] Gergely Orosz. I personally had great success in building an engineering team, where everyone saw themselves as leaders - and has the opportunity to exercise this skill. Beyond the additional logistics load on the manager, to have enough, good-sized projects to lead, I saw little downsides to this approach.