We read the spec and find the functionalities We break down tasks In most of the cases the goal of the breakdown is to come up with an estimation and plan of works. We distribute the works among team members. We design the database schema - sometimes by the team leader or sometimes by the respective developer. We start coding So? What’s wrong with this approach? We have been doing good! Don’t we?
years Your project has the same functionality implemented in the same way or different in different places You have more than one object for the same item You have objects that have properties that are not actually attributes of that object. You have no or very poor relationship among related items. Looking at your objects it is not possible to understand what actually the whole application is all about Bottom-Up fashion So, is traditional approach – “Designing the application starting from database” a throw away concept? Not really! But if you have a complex application to develop, this bottom-up design approach does not dictate you to come up with a proper object oriented design.
DDD? Domain-driven design is not a technology or a methodology. DDD provides a structure of practices and terminology for making design decisions that focus and accelerate software projects dealing with complicated domains.
to developing software for complex needs by deeply connecting the implementation to an evolving model of the core business concepts. is much more than just a proposed Architecture; it is also a way of dealing with projects, a way of working as the development team, the importance of identifying an “Ubiquitous language” whose planning is based on knowledge of domain experts (business experts), etc. Domain-driven design is not a technology or a methodology
development of the different applications within an organization. • Easy application maintenance because different types of tasks are always situated in the same areas of the architecture. • Easy change of the topology in the physical deployment of an application (2-Tier, 3-Tier, etc.), since the different layers can be physically separated more easily.
very small applications, we add excessive complexity (layers, loose- coupling, etc.). In this case it might be over-engineered. But this case is very unlikely in business applications with a certain level of complexity.
activity. The subject area to which the user applies a program is the domain of the software. Let’s say you are engaged to design a building. The requirement is: You have a defined amount of land Your building will have 6 floors. Each floor will have 4 apartments. What is your domain here? The domain is Building(?). No it should be Residential Building
the business should share a common language that both understand to mean the same things, and more importantly, that is set in business terminology, not technical terminology The length and width ratio of the smaller bed rooms would be 4:3 Correct Language: The children's bed room’s length will be 20 ft and width will be 15 ft. Note that, to the owner of the building “smaller room”, “ratio” - all these things could be very technical terms. Rather it is easier for him to understand children's room, guest room, living room etc. And explicit measurement is more meaningful to him.
considered as a small application, containing its own Domain, own code and persistence mechanisms. Within a Bounded Context, there should be logical consistency; each Bounded Context should be independent of any other Bounded Context. Dividing a large application among different bounded contexts properly will allow you to make your application more modular, will help you to separate different concerns and will make the application easy to manage and enhance Each of these Bounded Contexts has a specific responsibility By splitting these apart it becomes more obvious to find where logic should sit, and you can avoid that BBOM (Big ball of mud)
Electricity supply Electricity supply Apartment Etc Question1: Can you imagine a window without a room? Question2: Does a window have any identity without the room it is residing in?
it, but this one is mine The key defining characteristic of an Entity is that it has an Identity – it is unique within the system, and no other Entity, no matter how similar is, the same Entity unless it has the same Identity. Example : Your bed room in the apartment. Article in CodeProject
that are considered as a whole unit with regard to data changes If the aggregate’s objects need to be persisted in the database, then they should only be accessed through the root entity public class Computer : IEntity, IAggregateRoot { public Hardware Hardware { get; set; } public Software Software { get; set; } } public class Hardware : IEntity { } public class Software : IValueObject { } public class Repository<T> : IRepository<T> where T : IAggregateRoot {}
and where the data of your domain will persist or even if the data do need to persist while you do the model of the domain. Entity will keep it is status until it be saved
with many domain object types and many possible queries, Repository reduces the amount of code needed to deal with all the querying that goes on. Repository promotes the Specification pattern which encapsulates the query to be performed in a pure object-oriented way. A Repository mediates between the domain and data mapping layers, acting like an in-memory domain object collection. Client objects construct query specifications declaratively and submit them to Repository for satisfaction.
platform, this option should be kept in mind if you want to create an entity model mapped to a relational database. EF model generates native SQL statements required for each DBMS, so it would be transparent whether we are working against SQL Server, Oracle, DB2 or MySQL, etc. • ADO.NET: Consider using ADO.NET base classes if access to a lower API level is required. This will provide complete control over it (SQL statements, data connections, etc.) but relinquish the transparency provided by EF. • Microsoft P&P Enterprise Library Data Access Building Block: This data access library is based on ADO.NET. However, if possible, I recommend using Entity Framework instead (Old Library). • ADO.NET Sync Framework: Consider this technology if you are designing an application that should support scenarios occasionally disconnected/connected or that require cooperation between the different databases. • LINQ to XML: Consider this technology when there is an extensive use of XML documents within your application and you want to query them through LINQ syntax. • Third party technologies: There are many other good technologies (ORMs like NHibernate, etc.) which are not provided and supported by Microsoft.
mas3oude
mackey0225
hanhan1978
kishida
izumin5210
pyama86
chiroruxx
kentaroutakeda
mugi_uno
bkuhlmann
sonatard
polamjag
xhochy
colly
tenderlove
aleyda
philhawksworth
mraible
mthomps
marktimemedia
shpigford
notwaldorf
mclloyd
holman
speakerdeck
