Wie richten Sie Ihre Teamstruktur an domänengesteuerten Designkonzepten aus?

DDD is a way to create software, think of writing a fiction book, before you start you make an outline, you pack in all the little things you can in the outline to give context to the chapters, stories, locations. You also have a plot, characters, and even character development. DDD says, before you start developing the solution you want to identify how the business would solve that problem. One of the biggest issues in any profession is using templates. People get narrowed into making their content fit the template instead of brainstorming what their outline should look like. One big reason I didn't like PMP before they made their recent agile changes. All PMs approached everything the same and it didn't work.

Few pre-requisites like •Regular access to business domain SMEs. •IT team should possess good modeling and design skills. •Analysts should have good business process modeling skills. •Architects and developers should have strong OOD and Programming (OOP) experience. Agile methodology (SCRUM or Distributed SCRUM) is a great fit here because it focuses on the delivery of business value just like DDD focuses on the alignment of software system with business model The main elements of DDD such as Entity, Value Object, Service etc. or they talk about concepts like Ubiquitous Language, Bounded Context and Anti-Corruption Layer. So, team should align with Specific business capabilities or services that the bounded context represent.

DDD aims to create software that closely mirrors the business domain it serves, making it easier to understand, modify, and extend. It encourages collaboration between technical and domain experts and ensures that the software evolves in a way that aligns with the business’s evolving needs. In DDD, services are operations or actions that don’t naturally fit within an entity or value object. Domain services contain domain logic that doesn’t naturally belong to an entity or value object. For example, 1. a service that calculates the total cost of an order. 2. A service that calculate the interest based on the rate Bottom line isolates the business logic from the presentation layer.

You must include everyone you need from the start; you will find challenges where resources don't belong to you, or they are missing. Put in the hard work to communicate with stakeholders to get the team you need. If your job is to build a house, you need many roles, software is the same. PM, BA, Developers, Business users, power users, and so on. Sometimes your pod or group will have different businesspeople in it but the same PM/BA/Devs. You need to think full circle, who are the end users, business users, executives getting insights from it, reporting, views. I have to allow my customers to get what they need, my employees what they need, and as an Executive, big pig portfolio insights. You have to walk the dog as I say. Go through it.

You will find that large teams will get nowhere really fast, if they don't all meet regularly AND, have leadership, vision, and accountability. It is not enough for me sometimes to give my vision to the team and expect it to go well. I have many development teams developing different business functions, but if I don't drop in often, lead, speak my vision, talk about what the end user CISO or Board Members want, you just get data, not necessarily organized or normalized and definitely not insightful. If I had 100 problems, 99 of them would be communication related. "The single biggest problem in communication is the illusion that it has taken place" George Bernard Shaw. AND as they say in the Navy - Keep It Simple, Stupid! (KISS)

Building on the premises in my contributions above, with a strong team in place, you need business leaders making discretionary calls about their work. I'm not a business expert in many of the functional areas I'm responsible for, so I get the team, resources, visions, and other items together but need functional SMEs to address tactical items. Sometimes they can tackle strategic or cross functional collaboration, sometimes they can't. You have to make sure the right resource(s) are leading the decision making of the team to address all expected benefits otherwise you need to step in. Give them autonomy, and space. Successful leaders can delegate and empower (the right people). You cannot be everywhere all the time.

What the article said. The larger you get the more you need to make all the teams aware of the skills, talents, and work your other teams are doing. You don't want to miss the forest for the trees, everyone needs to understand the larger situation or problem. Its not enough to read the latest book, listen to a podcast, or get a cert. You have to continuously learn about the capabilities of the larger team, how collectively you are all solving the issue. You will not only get new insights and better solutions, prevent issues ahead of time, but you will get a connected workforce who truly understand where they stand in the bigger picture and everyone and thing will be better off for it.