Related
My team manages software delivery using Azure DevOps. Our SDLC is typical:
EPIC
Feature
Requirement
Acceptance Criteria
One question has arisen, we work in an agile fashion (Adaptive SCRUM), when we go through a refinement session with our Users, where is the best place to capture some design details?
We have tried:
Acceptance Criteria for Users, but this has the Senior Architects upset - they want all technical details to maintain an architecture repository.
Wiki - This, has a whole bunch of people upset because the WIKI only demonstrates what we intend to deliver.
Our main concern is maintaining the existing technical artefacts/documentation. We have very large pieces of commercial software, at any moment we need to be able to explain where things are.
We struggled with this after COVID, we realised that we don't know how certain things are built or designed.
Can somebody please explain (in succinct terms) what exactly is domain driven design? I see the term quite a lot but really don't understand what it is or what it looks like. How does it differ from non-domain driven design?
Also, can somebody explain what a Domain Object is? How does domain differ from normal objects?
EDIT:
As this seem to be a top result on Google and my answer below is not, please refer to this much better answer:
https://stackoverflow.com/a/1222488/1240557
OLD ANSWER (not so complete :))
In order to create good software, you have to know what that software
is all about. You cannot create a banking software system unless you
have a good understanding of what banking is all about, one must
understand the domain of banking.
From: Domain Driven Design by Eric Evans.
This book does a pretty good job of describing DDD.
Register to download a summary of the book.
Domain Driven Design is a methodology and process prescription for the development of complex systems whose focus is mapping activities, tasks, events, and data within a problem domain into the technology artifacts of a solution domain.
The emphasis of Domain Driven Design is to understand the problem domain in order to create an abstract model of the problem domain which can then be implemented in a particular set of technologies. Domain Driven Design as a methodology provides guidelines for how this model development and technology development can result in a system that meets the needs of the people using it while also being robust in the face of change in the problem domain.
The process side of Domain Driven Design involves the collaboration between domain experts, people who know the problem domain, and the design/architecture experts, people who know the solution domain. The idea is to have a shared model with shared language so that as people from these two different domains with their two different perspectives discuss the solution they are actually discussing a shared knowledge base with shared concepts.
The lack of a shared problem domain understanding between the people who need a particular system and the people who are designing and implementing the system seems to be a core impediment to successful projects. Domain Driven Design is a methodology to address this impediment.
It is more than having an object model. The focus is really about the shared communication and improving collaboration so that the actual needs within the problem domain can be discovered and an appropriate solution created to meet those needs.
Domain-Driven Design: The Good and The Challenging provides a brief overview with this comment:
DDD helps discover the top-level architecture and inform about the
mechanics and dynamics of the domain that the software needs to
replicate. Concretely, it means that a well done DDD analysis
minimizes misunderstandings between domain experts and software
architects, and it reduces the subsequent number of expensive requests
for change. By splitting the domain complexity in smaller contexts,
DDD avoids forcing project architects to design a bloated object
model, which is where a lot of time is lost in working out
implementation details — in part because the number of entities to
deal with often grows beyond the size of conference-room white boards.
Also see this article Domain Driven Design for Services Architecture which provides a short example. The article provides the following thumbnail description of Domain Driven Design.
Domain Driven Design advocates modeling based on the reality of
business as relevant to our use cases. As it is now getting older and
hype level decreasing, many of us forget that the DDD approach really
helps in understanding the problem at hand and design software towards
the common understanding of the solution. When building applications,
DDD talks about problems as domains and subdomains. It describes
independent steps/areas of problems as bounded contexts, emphasizes a
common language to talk about these problems, and adds many technical
concepts, like entities, value objects and aggregate root rules to
support the implementation.
Martin Fowler has written a number of articles in which Domain Driven Design as a methodology is mentioned. For instance this article, BoundedContext, provides an overview of the bounded context concept from Domain Driven Development.
In those younger days we were advised to build a unified model of the
entire business, but DDD recognizes that we've learned that "total
unification of the domain model for a large system will not be
feasible or cost-effective" 1. So instead DDD divides up a large
system into Bounded Contexts, each of which can have a unified model -
essentially a way of structuring MultipleCanonicalModels.
You CAN ONLY understand Domain driven design by first comprehending what the following are:
What is a domain?
The field for which a system is built. Airport management, insurance sales, coffee shops, orbital flight, you name it.
It's not unusual for an application to span several different domains. For example, an online retail system might be working in the domains of shipping (picking appropriate ways to deliver, depending on items and destination), pricing (including promotions and user-specific pricing by, say, location), and recommendations (calculating related products by purchase history).
What is a model?
"A useful approximation to the problem at hand." -- Gerry Sussman
An Employee class is not a real employee. It models a real employee. We know that the model does not capture everything about real employees, and that's not the point of it. It's only meant to capture what we are interested in for the current context.
Different domains may be interested in different ways to model the same thing. For example, the salary department and the human resources department may model employees in different ways.
What is a domain model?
A model for a domain.
What is Domain-Driven Design (DDD)?
It is a development approach that deeply values the domain model and connects it to the implementation. DDD was coined and initially developed by Eric Evans.
Culled from here
Here is another good article that you may check out on Domain Driven Design. if your application is anything serious than college assignment. The basic premise is structure everything around your entities and have a strong domain model. Differentiate between services that provide infrastructure related things (like sending email, persisting data) and services that actually do things that are your core business requirments.
Hope that helps.
As in TDD & BDD you/ team focus the most on test and behavior of the system than code implementation.
Similar way when system analyst, product owner, development team and ofcourse the code - entities/ classes, variables, functions, user interfaces processes communicate using the same language, its called Domain Driven Design
DDD is a thought process. When modeling a design of software you need to keep business domain/process in the center of attention rather than data structures, data flows, technology, internal and external dependencies.
There are many approaches to model systerm using DDD
event sourcing (using events as a single source of truth)
relational databases
graph databases
using functional languages
Domain object:
In very naive words, an object which
has name based on business process/flow
has complete control on its internal state i.e exposes methods to manipulate state.
always fulfill all business invariants/business rules in context of its use.
follows single responsibility principle
DDD(domain driven design) is a useful concept for analyse of requirements of a project and handling the complexity of these requirements.Before that people were analysing these requirements with considering the relationships between classes and tables and in fact their design were based on database tables relationships it is not old but it has some problems:
In big projects with complex requirements it is not useful although this is a great way of design for small projects.
when you are dealing with none technical persons that they don,t have technical concept, this conflict may cause some huge problems in our project.
So DDD handle the first problem with considering the main project as a Domain and splitting each part of this project to small pieces which we are famous to Bounded Context and each of them do not have any influence on other pieces.
And the second problem has been solved with a ubiquitous language which is a common language between technical team members and Product owners which are not technical but have enough knowledge about their requirements
Generally the simple definition for Domain is the main project that makes money for the owners and other teams.
I do not want to repeat others' answers, so, in short I explain some common misunderstanding
Practical resource: PATTERNS, PRINCIPLES, AND PRACTICES OF DOMAIN-DRIVEN DESIGN by Scott Millett
It is a methodology for complicated business systems. It takes all the technical matters out when communicating with business experts
It provides an extensive understanding of (simplified and distilled model of) business across the whole dev team.
it keeps business model in sync with code model by using ubiquitous language (the language understood by the whole dev team, business experts, business analysts, ...), which is used for communication within the dev team or dev with other teams
It has nothing to do with Project Management. Although it can be perfectly used in project management methods like Agile.
You should avoid using it all across your project
DDD stresses the need to focus the most effort on the core subdomain. The core subdomain is the
area of your product that will be the difference between it being a success and it being a failure. It’s
the product’s unique selling point, the reason it is being built rather than bought.
Basically, it is because it takes too much time and effort. So, it is suggested to break down the whole domain into subdomain and just apply it in those with high business value. (ex not in generic subdomain like email, ...)
It is not object oriented programming. It is mostly problem solving approach and (sometimes) you do not need to use OO patterns (such as Gang of Four) in your domain models. Simply because it can not be understood by Business Experts (they do not know much about Factory, Decorator, ...). There are even some patterns in DDD (such as The Transaction Script, Table Module) which are not 100% in line with OO concepts.
I believe the following pdf will give you the bigger picture. Domain Driven Design by Eric Evans
NOTE: Think of a project you can work on, apply the little things you understood and see best practices. It will help you to grow your ability to the micro service architecture design approach too.
Get an organization wide understanding of the problem domain by
developing a ubiquitous language (a common mental model) per sub-problem-domain.
Use that language as close as possible in solution domains (code).
Only then choose technologies.
Don't be technology driven but problem domain or business driven.
I have been search about SharePoint Governance for past few days, the more I search, more confused I am getting about this Topic.
Could anyone just explain in brief? What you know about it or are you using/implementing it?
This is one of those topics that tend to mean something a bit different when you get to the details for different companies, but basically here's my experience with it.
When you talk about governance its about who is responsible for different elements of it, from defining and managing the taxonomy, to the content for different areas. What the process of publication is, for modification is. Who administers different sections, how documents are to be handled/managed/archived/retained, what the auditing policy is. How escalations will be managed, who needs to be notified, who the stakeholders are, etc.
Basically in other words it's about looking at SharePoint as being not just a content storage system but needing to be a coherent enterprise tool with all of the key stakeholders sitting up and taking notice, and recognizing that some things need clear process to avoid either redoing everything in 18 months or being unable to find things.
Some of the most important things that I find ends up getting discussed is security (internal vs. external access, employees vs. contractors vs. external people, logging of who accessed files, etc.), roll back & geographic distribution (for performance), and revocation of rights (when someone is fired, how is their access revocation managed quickly and effectively).
Sorry this is a bit of a shotgun answer, but that's the type of stuff you're looking at. There are actually consultants who have specialized in these areas. It's usually (from what I experience) about 20% technical, 40% change management and 40% process / business.
I hope that helps.
Having recently discovered design patterns, and having acquired the excellent Head First Design Patterns book (can really recommend it!), I am now wondering about design patterns for security and controlling access to records in data stores.
My use case is a bespoke CRM style application, with contacts, businesses, and users who have different levels of access, including being limited to read only access, or even a subset of records. I will only be doing distinct entity level access control, not field level.
Can anyone recommend any security orientated design patterns that would fit the above?
If it makes a difference, I am using ASP.Net MVC, Entity Framework 4 and SQL Server 2008.
Security is what we call Cross-cutting concern and it's never easy deal with.
If you need to deal with the security from ASP.NET MVC level you would consider to look at MVC tutorial :
http://www.asp.net/learn/mvc/
If you want to know more about the security from the domain model level, an interesting question was already asked :
DDD User Security Policies
Hope this helps
There does exists a group of patterns realted to security, though most of them fucuses on securing integrated systems. I have found no book that is as well written and usable as GOF/Head-first, though I did enjoy the one online at www.securitypatterns.org.
Security is as much about architecture (sever setup, network topology...) as its about programing, so I would recommend that you start out with a general security book. Also pick up a book specifically on .NET/Windows security, since robust security programming is very technology specific (I, as UNIX/Java programmer, will have a completly different toolbox than
a .NET programmer and can unfortunatly not help you with a book on this last subject).
A good place to start on security (although not necessarily a "security design patterns" book) is Ross Anderson's Security Engineering.
At our company we are currenty trying to define the basic things our software architects have to know about SharePoint for them to architect and/or lead a SharePoint implementation project. Many architects in our company have a .NET developer background and know a lot about .NET development and the various framework components and tooling. However, they currently lack SharePoint knowledge. In fact they don't even want to know the nitty gritty details. They want to know just enough about it to make the right architectural decisions and apply proven patterns. If more specific knowledge is required they'll ask a SharePoint expert.
So What would is the basic set of SharePoint knowledge / skills that an architect would need to have?
Skills such as list, documents, workflow, permissions... are a bit too basic and are requirement for a SharePoint DEVELOPER.
I'd argue that perhaps site (and site structure) is an area that would fall under the architect's plate.
There are more areas that a SharePoint architect can help with:
Capacity planning - running multiple servers in a farm. Scalability and other magic words.
Knowing the capabilities and business scenarios of using SharePoint - this is a very common one.
The manager asks: what can SharePoint do for me?
The developer asks: well, what do you want it to do.
The manager then asks: well, I don't know what it can do for me so how do I know what do I want it to do?
Closely related to SharePoint capabilities are the various licensing costs related to each component.
As well as familiarity with development and customization costs. Take the same project time that would have taken in ASP.NET, then multiply it by a large coefficient, and then add an additional constant.
And closely related to what-can-it-do, and how-much-does-it-cost, is the all important question of Return-Of-Investment. All hail supreme ROI!
SharePoint deployment can be a massive issue and a lot of pain.
SharePoint upgrade from v2 (MOSS 2003) to v3 (MOSS 2007). We should be seeing a new version of SharePoint in 2010(?). Well soon after the next version of Office goes out the door. So past upgrade experiences may be useful.
Knowledge of 3rd party webparts. I believe a SharePoint architect should be able to give you at least 5 webparts that they've tried from CodePlex and tell you what they think about them. These are free and easy to grab and play at your own leisure.
Some knowledge of commercial webparts. Because they are still cheaper than writing your own.
Have at least 5 SharePoint blogs that they follow religiously (know the community). If not having their own SharePoint blog (give back to the community).
If they are on StackOverflow they must try to answer SharePoint questions (such as this one).
Attend local SharePoint usergroups. I think communities are a huge deal. Especially what you'd learn from talking with people directly and learning what they are doing with their SharePoint installation. You may just surprise yourself.
Experiences with SharePoint Integration - this comes in two equally important flavours - both from SharePoint accessing existing systems (business catalogs, webparts, etc), as well as other systems accessing SharePoint content via webservice or API.
In addition, SharePoint works with (or works well) with Office, OCS, reporting services, performance point, project server.
SharePoint hosting arrangements - Microsoft SharePoint online services can be a popular and cheaper option to start using SharePoint. It can be hosted inhouse, or with a 3rd party company. Knowing the options is always useful.
Must have read SharePoint code using reflector (and preferably still having hair).
I think it takes at least a couple of years to be a SharePoint architect (your mileage may differ). Your .NET architects need to want-to-be a SharePoint architect, otherwise I agree with other's summaries before me - find someone who already is a SharePoint architect.
An architect should have quite a good understanding of our a product works, from a functional and technical viewpoint.
So in my opinion, an architect should:
Have been involved in at least 2 Sharepoint deployments, from design to roll-out.
Have knowledge of our the major sharepoint components can be used using the API.
i.e. Sites, Lists, Documents & Workflow components.
As none of your architects have this knowledge, I would pair them with a Sharepoint expert in an existing Sharepoint project, so they get the knowledge they need.
Ideally SharePoint Architect Skills fall into the below mentioned categories
Infrastructure Level/Operational
Capacity Planning
Physical Architecture (Farm Setup, Network, OS, Licensing)
Application level (Functional and Non-Functional)\
Requirement and Feasibility Analysis (Custom Vs OOTB Development/Implementation)
Techno-functional Mapping of requirements
Information Architecture
Logical Architecture
Conceptual Architecture
Detailed Design
Database design (not in terms of traditional Database design), this is with respect to Number of content Databases for Site collections/web apps.
Deployment
Best way to go for deployment, first time and incremental
Some other activities that an architect will collaboratively work is the Project Manager in Planning, Estimation, Execution/Implementation, Risk Management (assessment, mitigation).
Apart from his daily tasks of working with technical teams, testers, User Interface professionals, Vendors, Clients (Business and IT teams).
Interacting with Enterprise Architect groups if any.
In my not so humble opinion I think the entire "Sharepoint Architect"/"Expert" thing is over-played.
Sharepoint is a tool to centralize an organizations digital resources for centralized collaboration or working together in a centralized way.
The best explanation of What Microsoft Sharepoint is and does
from the WROX book "Beginning Sharepoint 2010 - Building Business Solutions"
"Because computers play such an integral part in any business, not surprisingly, more and more
of the information that is created, consumed, and shared in an organization is digital. The more
business that you conduct and the more successful your business becomes, the more information you
have to manage. Usually, you have some form of document for just about every process and transaction
that plays out during the day-to-day operations of your company. From proposals to legal
documents, from sales receipts to human resources policies, the amount of information required for
a company to function is staggering.
To manage your information overload, SharePoint offers tools with which you can build business
applications to better store, share, and manage digital information. With it, you can create lists,
libraries, and websites for your various company teams to help run your business processes more
efficiently. By locating your organization’s important business data in a single location, it becomes
much easier and intuitive for users to find the right information when they need it rather than
searching through disparate locations such as email, computer hard drives, or file shares.
WHAT IS SHAREPOINT 2010?
SharePoint 2010 is an extensible and scalable web-based platform consisting of tools and technologies
that support the collaboration and sharing of information within teams, throughout the enterprise and
on the web. The total package is a platform on which you can build business applications to help you
better store, share, and manage digital information within your organization. Because you can build
with or without code, the package empowers the average business user to create, deploy, and manage
team websites, without depending on skilled resources, such as systems administrators or developers.
Using lists, libraries, and web parts, you can transform team websites into business applications built specifically around making your organization’s business processes more efficient."
Creating a schema for an organizations Sharepoint deployment is not rocket science. 1. Determine the structure of the organization 2. Determine what Sharepoint can do as far as centralizing the organizations digital resources. 3. Create a Sharepoint construction plan. 4. Build it, test it, refine it. 5. Maintain it, test it, refine it, add onto it. There! Not so tough.
Sharepoint can be a nasty beast to work with if you don't know the ins and outs of it (they should be experts with it to architect it). At a minimum, they should know how lists, sites, and permissions work. Ideally they should also know how all the web parts fit together on pages and how they are supposed to interact. Really if the architects don't want to learn about sharepoint, they are going to create a .net web application and force it to run on sharepoint. It won't really follow the paradigm of how a sharepoint app is supposed to work.
I would look at a company called Mind Sharp for guidence as to what they should learn.
My advice is look for a doer that doesn't just reads PowerPoint to much in the Sharepoint world is just based on what other people have said.
We have been having issues with crawling 500000 items in a Sharepoint farm and everyone gives another story how to get better speed... Normally people refer to not more than 2000 items in a folder, but that does not change the crawl speed....
So a good architecture is someone who is able to do POC proof of concepts himself of his design and not just refers to some vague stories.....
I have seen to many Sharepoint Architects that hasn't had experience from real life....